Make an RFC for bi-camerality vs tri-camerality

[jeapostrophe]

read, enforest (Honu), parse

[michaelballantyne]

@jeapostrophe a brief explanation of your idea of "tri-camerality" would be great---I can't guess what the third bit from read and parse is.

[spdegabrielle]

I'm guessing from page 9 of PLAI that bi-camerality refers to read => parse and tri-camerality refers to read => expand => parse

I think in this case readcreates an intermediate syntax tree as per Homoiconicity isn’t the point by David Herman

PLAI https://cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-04-26/plai-2007-04-26.pdf Pic from http://calculist.org/blog/2012/04/17/homoiconicity-isnt-the-point/ by @dherman

[jeapostrophe]

No, I did not intend expand to be the third step. I really meant what Honu does.

The point of this item is to discuss the idea that although Racket 2 won't be parenthetical, it will have a simple predictable rule for determining what goes together. For example, if we look at a program like if c t else f where x = 3 we have to determine whether the where goes with the f or the entire if. In Racket it is clear because you'd have either ((if c t f) . where . [x 3]) or (if c t (f . where . [x 3]))

In Honu, if I understand correctly, the if macro has access to the entire stream and it could enforest as (if c t f) where x = 3 and then the where macro would take over and enforest as (where (if c t f) [x 3]) OR if/where could behave differently. In other words, you need to understand the implementation of the macros to determine what goes together. This, IMHO, is a disadvantage of tri-camerality and I think that bi-camerality is superior.

[spdegabrielle]

Thank you for ref https://docs.racket-lang.org/honu/Parsing.html