Issue SHARP-COMMA-CONFUSION Writeup

Forum:		Compiler

Issue:		SHARP-COMMA-CONFUSION

References:	CLtL p. 356

		Issue LOAD-TIME-EVAL

Category:	CHANGE

Edit History:   V1, 17 Oct 1988, Sandra Loosemore

		V2, 30 Dec 1988, Sandra Loosemore (comments from Pitman)

Status:		Proposal REMOVE passed Jan 89



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.



Proposal SHARP-COMMA-CONFUSION:REMOVE:


Remove the #, read macro from the language.



Rationale:


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

pathnames.)



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:


None.



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.



Benefits:


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.



Discussion:


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 

     applications.

   - I want the records to reflect the actual rationale people should and 

     hopefully will be using to make these decisions.