[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue: SYMBOL-MACROLET-UTILITY (Version 1)
- To: DECWRL::KMP@stony-brook.scrc.symbolics.com
- Subject: RE: Issue: SYMBOL-MACROLET-UTILITY (Version 1)
- From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
- Date: Wed, 29 Jun 88 10:54:12 PDT
> You called the proposal SYMBOL-MACROLET:FLUSH rather than
> 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
> * 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?