Rassum frassum if you kids didn't have all that syntax you would never think not to put a lambda there. Wait, what am I saying, I worked on Common Lisp.

Mike Dixon improved things considerably with SEdit, a structure editor that temporarily converted to a more text editor like mode. So the editing was less clunky. But the primary representation was still s-expressions, not text.

In IP, *as I understood it*, you needed the sophisticated tooling to make any sense of the code. That's because the direction was higher-level model to lower level code, not "what we call code today" -> registered to multiple higher levels where it can be edited.

I'm sure you (won't) love this, but you're starting to sound a little like the intentional programming direction there. Although again, it's a matter of what you take the base to be - or put another way, how easy is it to get work done with this the base and a plain text editor.

Yes, you want to include all of that for sure. Uuencoding it is one approach. Another is to use some kind of UDI scheme (or GitHub locator) and just leave the link in place. Again, I think preserving the ability to work with a minimal tool is key, if only during adoption (which lasts forever).

register (not quite parsing) that, and see and edit it in different ways. That would get more flexibility in view, and preserves the affordances of text based representation and comments for the primary source.

In fact, that’s the thing I was try to say in my too-unclear OOPSLA 2007 talk. That we should get flexibility in how we see and edit code by going the other direction - take text-based files based on one standard syntax as primary, and then be able to

Any kind of formatting of the comment was impossible. If you popped up a narrow window to look at a function then it appeared quite differently than it looked in a wide window.

That was a long time ago, things might be different now, but I’m still doubtful that’s the “direction” to go.

In Interlisp you could put comments before any expression, but the comment itself was an S-expression – something like (comment here is something interesting about the next expression.) Interlisp was case preserving by default so it worked out alright. But only alright.

Interlisp-D and Smalltalk tried a world in which an internal representation of code was rendered each time before it was edited. But text file-based code representation won out. I THINK because the affordances of lightweight code and comment formatting are pretty great.

This is excellent, thanks for writing it. XML and S-expressions are the same in just the ways you say. And thanks for debunking homiconicity.

I agree with all you are saying up to “just one of many views onto the core abstract syntax”.