Issue: SYMBOL-MACROLET-SEMANTICS (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.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
   change.

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

   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.