Sometimes it takes me 22 years (+ one evening) to write a blog post. Here are my thoughts on "homoiconicity" and, as an alternative, "bicameral syntax". (Warning: 4000 words.)
https://parentheticallyspeaking.org/articles/bicameral-not-homoiconic/
https://parentheticallyspeaking.org/articles/bicameral-not-homoiconic/
Comments
And that there are a number of ways to add quasis.
https://web.archive.org/web/20220524085614/https://temperlang.dev/design-sketches/parsing-program-structure.html
- a cover grammar conflates forms like `if` w/ block-receiving macro calls
- a bespoke operator precedence parser builds lispy trees
- operator trees can flatten to pseudo token lists and parser combinators can recover special forms from them
- recovery can be redone after macros munge trees
OK to say "who cares, not needed for practical purposes", but formal language people get sucked into studying other things far in excess of what is needed for practical purposes.
Also, there's an extensive theory of transducers…
I agree with all you are saying up to “just one of many views onto the core abstract syntax”.
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.
That was a long time ago, things might be different now, but I’m still doubtful that’s the “direction” to go.
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
2. This library offers a very limited syntax. It is not "equivalent" to what you get from bicameral languages, which are inherently extensible.
And the cost is that Forth and Smalltalk can't be analyzed in the same way as modern PLs -- do I have that tradeoff right?
I think Forth's analysis challenges are peculiar because you can modify things on the fly. Can a Smalltalk program modify itself?
The original Smalltalk-72 could change the syntax side of things. A message send included the rest of the code, untokenized and unparsed. Later Smalltalks were more locked down.
https://hackage.haskell.org/package/replace-megaparsec-1.5.0.1
Your essay about bicameral syntax is the first time I've read a principled reason (other than speed) about why a regular parsing pass is a good idea.
One small quibble: I think your consideration of Homoiconicity is a bit of a straw man. There are different, much better (i.e. more well thought out) definitions than the ones you compare against. My favorite:
https://www.expressionsofchange.org/homoiconicity-revisited/
(typo: “Scaner --> Reader --> Parser”)
I was going to turn those into images anyway once I can remind myself of the details of the pict library, so I'll fix it then. Thanks!
Only complaint is your choice of term. It’s good but doesn’t sound sciency enough to feel clever saying it😅
Fun fact: your post was deleted by the mods🤣