Issue: SYMBOL-MACROLET-UTILITY (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

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

I personally oppose this proposal, but I of course have no opposition to
it's being presented to X3J13 for a vote.

This is a very complex issue, and I don't think it does it justice
to have such a terse presentation. I think both the specific reasons
why people dislike it (I believe there to be interesting semantic 
arguments which go beyond a desire for a minimalist language)
and the specific reasons why people think it's an important new language
feature need to be brought out.

Issues I'd like to see added at appropriate points (perhaps in the
discussion):

 * Current Practice

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

 * 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.

 * 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.

 * 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 think there other issues lurking here as well, but these should do as
starters to help flesh out this proposal.