Okay, so I read the Honu paper more and more.
Honu *does* have a separate reader and macro-expander.
However, Honu's approach means that what Honu does is effectively turn
code like this:
function foo(x, y) { x + y; }
to this s-expression:
(honu-block function foo (x |,| y) ((x + y)) )
I'm *not* sure that the Honu reader actually does that - the Honu
reader probably emits just (function foo ....) and the Honu language
(using Racket's language system) tacks on the honu-block before it.
The honu-block macro is a Scheme-level (actually, Racket-level, since
RnRS macros are just syntax-rules) macro.
Honu-level macros are *different* from Racket macros and are handled
differently (by my understanding, using Racket's expansion-time
environment to somehow store them while honu-block processes things).
This works for Honu because of the Pratt parsing enforced by
honu-block, meaning that the (x + y) part will be seen by Honu-level
macros as something practically close to (+ x y). Because of the
tacked-on honu-block keyword, honu-block has full control of what
Honu-level macros see.
Still, it seems that Honu significantly obscures the code-is-data part
of Lisp, because of the significant transformations that honu-block
performs on its input list.
1. Honu is not very back-compatible with Lisp. Our approach allows
valid parsing of "string->symbol", Honu seems likely to convert that
to three atoms, 'string '-> 'symbol. Our approach also allows a large
amount of existing, typically-formatted Lisp code to be parsed
identically to existing 'read; Honu makes changes that prevent
existing Lisp code to be read in, in conjunction with Honu code (i.e.
you can't copy-paste existing Lisp code into a Honu language file; you
can copy-paste existing Lisp code into a sweet-expression file most of
the time)
2. Actually, Honu *can* support quote. It's just that the syntax of
lists in quote doesn't match the syntax in the rest of Honu. In Honu
a list is [1,2,3]. But in a quote context it's (1 2 3) (I think).
I'm not sure what the term sequence "quote [1,2,3]" would expand to,
but I suspect it's something like (quote (honu-bracket 1 |,| 2 |.|
3)). So, lose homoiconicity and generality just in this one stroke.
3. Honu requires a macro-expansion pass to convert a + b to (+ a b).
Sweet-expressions does not require a macro-expansion pass to convert
{a + b} to (+ a b). This may not seem significant, unless you're,
say, writing a 4X game where your unit descriptions may need small
amounts of interpreted code, and because this is a unit description
file and you don't want your users to suddenly e-mail /etc/passwd to
an undisclosed third party when all they wanted to do was try out a
neat new unit description file they got off the internet, you're not
interested in giving the full power of macros in the little bits of
code, but you *are* interested in allowing the unit description file
to say "define power(berserker) { power(scout) + 2 }" (i.e. Principle
of Least Power).
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Readable-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/readable-discuss
