[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Issue: SYMBOL-MACROLET-UTILITY (Version 1)



> You called the proposal SYMBOL-MACROLET:FLUSH rather than
> SYMBOL-MACROLET-UTILITY:FLUSH.

Oops.

 
>    Symbolics Cloe has both a code-walking version of a SYMBOL-MACROLET
>    macro and compiler support for a SYMBOL-MACROLET special form.

I'll add this to current practice.
 
>  * Abstraction / Expressive Power
>  
>    Symbolics Cloe originally started with the macro version of
>    SYMBOL-MACROLET, but found that the problem is that a code-walking
>    SYMBOL-MACROLET destroys important abstraction information (like the
>    fact that a particular TAGBODY/GO/BLOCK/RETURN configuration can be
>    viewed as a PROG/PROG*/DO/DO*/...). There's no loss of computational
>    power by doing the expansion, but there is a loss of perspicuity and
>    it is not always easy for a compiler to put that information back in.

This seems to have to do with whether SYMBOL-MACROLET should be a macro or a
special form.  I've written (but not yet distributed) a separate issue for
this, but I'd like to first see debate on the keep/flush question.  Note that,
as voted, CLOS specifies SYMBOL-MACROLET to be a macro, which implies code
walking.
 
>  * ONCE-ONLY
>  
>    If I recall correctly, some people have a worry about the relationship
>    between SYMBOL-MACROLET and ONCE-ONLY (an interesting macro which
>    occurs in several implementations). I haven't thought hard about this
>    issue, but maybe someone who has can comment on it.
>  
>    Note that if users write their own code-walking SYMBOL-MACROLET, the
>    wrong interaction may happen with a ONCE-ONLY primitive and there's
>    no obvious way to work around the problem.

Again, this is a code-walking-vs.-special-form issue.  I agree that, if
admitted to the language, SYMBOL-MACROLET should be a special form, not a
macro.  However, I also believe that that's a different question.
 
>  * Need by users
>
>    I've wanted this feature on a number of occassions to help me implement
>    embedded languages. I bet others have, too. I think that wants to at 
>    least get mentioned somewhere. When arbitrary users come up with the
>    need for this facility, it is unreasonable (both in terms of code
>    duplication and in terms of programmer expertise) to suppose that they
>    can or should just go out and write a code-walker. Having written one
>    myself, I must say I think that getting it right for even one 
>    implementation is very hard and making it really portable is almost a
>    pipe dream.
 
I'll include a mention about "embedded languages."  Of course, embedded
languages are not Common Lisp.  If one favors SYMBOL-MACROLET because it
supports embedded languages, then one "should" also favor souping up
readmacros to make READ a fully-general parser, for how else can we support
an embedded language like FORTRAN?

/JEP