[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

issue SHARP-COMMA-CONFUSION, version 2

This version of the writeup incorporates suggestions from Kent Pitman.

Forum:		Compiler
References:	CLtL p. 356
Category:	CHANGE
Edit History:   V1, 17 Oct 1988, Sandra Loosemore
		V2, 30 Dec 1988, Sandra Loosemore (comments from Pitman)

Problem Description:

The way the read macro #, is defined in CLtL does not make it clear
that it can only appear inside of (implicitly) quoted structure to
guarantee consistent handling between the interpreter and the
compiler.  Examples of inconsistent uses would be #, forms appearing
outside of a QUOTE that expand into list or symbol forms that could be
interpreted as code, or strings that could be interpreted as
documentation strings.  Users are even more likely to be confused
because the wording in CLtL compares the behavior of #, to the special
form EVAL-WHEN, which must appear in a for-evaluation position.

#, also presents a serious problem to program-analyzing programs
because evaluation is tied to the reader, rather than the interpreter
or compiler.  In theory, this could be handled by altering the read table
to have #, construct a "magic cookie" instead of performing read-time
evaluation and having the code walker examine quoted structures, but I've
never seen this actually done in practice.


Remove the #, read macro from the language.


Removing #, is simpler than trying to redefine it.  Removing it from
the standard, rather than redefining it to mean something else (see
issue LOAD-TIME-EVAL), would allow implementations to continue to
provide it as an extension.  (Although CLtL does not appear to
explicitly address the question of whether implementations may extend
the reader syntax, some implementations already provide sharp-sign
read macros other than those described in CLtL, such as #P syntax for

Current Practice:

#, is not used very frequently, but the functionality it provides is
important in some advanced applications; one such application that has
been cited is CLOS.  Maintainers of such applications have generally
expressed a willingness to give up #, only if a suitable alternative
is offered (see issue LOAD-TIME-EVAL).

PSL/PCLS has never bothered to implement #, correctly (it's treated
just like #.), and nobody has ever complained about it being broken.

Cost to implementors:


Cost to users:

Because #, is used so infrequently, most users would probably not even
notice its absence.

Issue LOAD-TIME-EVAL proposes to add a special form that would provide
a somewhat cleaner mechanism for load-time evaluation.

It is also possible to use a global variable to get the similar effect as
#,, although this is sometimes awkward and carries a space and 
performance penalty in many implementations.


The language specification is simplified by removing a peculiar
feature of the language that is accessible only through the reader.

Removing #, may also allow simpler strategies for implementing
compiled file loaders to be used.


If this proposal is rejected, the definition of #, in the standard will
still need to be clarified to indicate that #, can only appear in
quoted structure.  It should probably also include some mention of the
problems that #, can cause code walkers.

Kent Pitman says:

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

  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 
   - I want the records to reflect the actual rationale people should and 
     hopefully will be using to make these decisions.