On Mon, 2009-08-24 at 11:18 -0700, Brian Harvey wrote:
> >  provide only low-level macros in Small Scheme
> 
> Cool!  I vote for FEXPRs -- I understand those.

Speaking as probably the only modern hobby lisp implementor 
whose lisp actually uses and develops the idea of FEXPRs -- 
(hmmm.  DEXPRs would be more appropriate at this stage of 
development, I guess) I'm advising you not to go there 
with scheme. 

When FEXPRs were last mainstream, they were 'unhygienic' in a 
very bad way; we did not have the level of environment theory 
we needed to keep their semantics straight. We got the 
environment theory, mostly, when we got hygienic macros - 
but nobody except me, AFAIK, has turned around and used it
to rebuild FEXPRs, because why do at runtime what you can
do at compile time, huh?

Now that that level of environment theory exists, and I have 
used it to build a hobby lisp, I know exactly what it takes to 
make this work cleanly. 

And what it takes is passing the environment in which the argument
is to be evaluated along with each argument, exactly the way a 
promise is represented, and putting argument evaluation under 
the control of the called function. 

On the plus side, given reflective abilities for accessing 
the environment and argument expressions as data, this makes 
macro calls and function calls have exactly the same core 
representation, so you don't even have to know which is which
when making a call.  In principle, everything has become a 
function, it's just that my functions can have first-order 
as well as first-class semantics.  You can store them in data 
structures, return them from functions, define them during 
runtime, apply them, etc. That's interesting, and it's why 
I did it.

On the minus side, this makes it hard to optimize or compile, 
and approximately doubles memory usage in invocation frames. 
This along with some other things like extended numerics is 
why my hobby lisp is whacking slow.  Also, it necessarily 
moves argument evaluation to the control of the called function, 
which is contrary to scheme's established semantics of argument
evaluation before functions are called.  These two reasons are 
why any sane scheme standards committee would reject FEXPRs as 
a decent option for a scheme macro system.  Of course there are 
also irrational reasons to do so, largely related to the 
remembered hair that FEXPRs caused back when we couldn't keep 
their semantics straight.

                                Bear



_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss

Reply via email to