CLHS: Issue SHARP-COMMA-CONFUSION Writeup

#

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

Copyright 1996-2005, LispWorks Ltd. All rights reserved.