issue SHARP-COMMA-CONFUSION, version 1

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

I approve of the ideas being discussed, but ONLY contingent on
LOAD-TIME-VALUE being introduced.

I don't think the current practice assesses things correctly.
Better than
 #, is not used very frequently.  
would be
 Although #, is used infrequently in typical user code, the functionality
 it provides is very important to some advanced applications. Maintainers
 of such applications have generally expressed a willingness to give up #,
 only if a suitable alternative is offered (see issue LOAD-TIME-EVAL).
CLOS and language translators are examples of pieces of code which have
been cited by people who say they could not be implemented efficiently in
Lisp without a facility such as this.

In Cost To Users, the DEFPARAMETER technique described has been demonstrated
to be unacceptable for the general problem. The importance of LOAD-TIME-EVAL
needs to be promoted here as well.

I am optimistic that LOAD-TIME-EVAL will pass, and so I don't think this
will keep #, from passing, but:
 - I want people who vote for this to realize the importance of voting
   for LOAD-TIME-EVAL.
 - On the off chance LOAD-TIME-EVAL doesn't pass, I want people to have
   been warned that the consequences were severe for some major applications.
 - I want the records to reflect the actual rationale people should and 
   hopefully will be using to make these decisions.

In particular, the issue of LOAD-TIME-EVAL goes beyond "thinking of a
variable name". A bunch of other issues which were raised in mail are 
left out here:
 - There is no way for an expression from inside a program for a macro
   to `emit' a top-level definition.
 - Variables are high overhead (typically at least five pointer-size 
   units per symbol), and so zillions of independent names would bloat
   space.
 - Variables are typically slower than immediate quantities can be.