[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: SYMBOL-MACROLET-SEMANTICS (Version 1)
- To: piazza%lisp.DEC@decwrl.dec.com
- Subject: Issue: SYMBOL-MACROLET-SEMANTICS (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 1 Aug 88 13:57 EDT
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <8807292109.AA03546@decwrl.dec.com>
I assume this is the SYMBOL-MACROLET-UTILITY issue in another guise,
though the edit history does not reflect that. Can we please just pick a
topic name and stick to it? I file these by topic and this kind of
mid-topic name shift (especially without clearly identifying the intent)
leaves me with two files, each containing half of the relevant mail.
Some comments on the writeup itself:
- I find the tone of the writeup to use a kind of bias that made it
hard to read. I'd be happier if the tone were more objective.
- Proposals should not talk about changing existing documents. 88-002R
is written, fixed, and basically cannot change. What you want to change
is the part of CL which was changed by its adoption. The convention in
cleanup proposals is to refer abstractly to changing the language, so
your proposal doesn't become obsolete as the names of reference documents
- The problem description does not adequately describe the problem.
I suspect this is related to the tone problem, which feels like it's
emerging out of the heat of a debate to be read by someone involved
in that debate rather than that it's something intended to be read
cold by the X3J13 members not following this discussion. The latter
should be the target audience. It should be possible to read the problem
description out of context and know something interesting about CL, and
I don't think you can do that with this writeup.
We have generally used the Test Case section to describe the
proposal, not the problem, so the problem description should at
least explicitly allude to the test case as being critical to the
problem description. In fact, though, I think you need more expository
text to make it really obvious what the issue was. The first three times
I read the problem description, I thought you were just griping about
the absence of &ENVIRONMENT information going into SYMBOL-MACROLET.
- I think the stated issue is really orthogonal to the proposed solutions.
For example, flushing the feature because it has a problem is the trivial
solution to almost any problem, so it doesn't really show whether your
solution is going anywhere.
The Special Form solution -- even though I like the idea of it being a
special form -- is not a solution to the stated problem. It makes this be
a non-issue for system-supplied things that can inspect the environment
information, but you don't provide access to that information for user
In my mind, part of the solution must involve the introduction of a
SYMBOL-MACRO-FUNCTION function, which is like MACRO-FUNCTION but tells
you if something is a symbol macro. This might be implementable portably,
though it would certainly be easier if it were a special form.
- I observe that the change to MACROEXPAND and MACROEXPAND-1 is probably
desirable, but that this isn't the only way to do it. For example, you
could have a separate function for expanding symbol-macros, or you could
funcall SYMBOL-MACRO-FUNCTION of the symbol. Probably changing MACROEXPAND
will be the most natural way to deal with it, but I wanted to note this
flexibility for the record.
- I'm personally happy to see the FLUSH option removed and have this proposal
elaborated around the special form solution since I don't think it's going
to fly and I don't personally want to waste time on it. I guess if everyone
doesn't agree on that, though, it's gotta be retained for now, though.