[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: SYMBOL-MACROLET-UTILITY (Version 1)
- To: piazza%lisp.DEC@decwrl.dec.com
- Subject: Issue: SYMBOL-MACROLET-UTILITY (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 28 Jun 88 16:53 EDT
- Cc: email@example.com
- In-reply-to: <8806281758.AA10391@decwrl.dec.com>
You called the proposal SYMBOL-MACROLET:FLUSH rather than
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
* 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.
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
I think there other issues lurking here as well, but these should do as
starters to help flesh out this proposal.