[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue SHARP-COMMA-CONFUSION, version 1
- To: firstname.lastname@example.org
- Subject: issue SHARP-COMMA-CONFUSION, version 1
- From: email@example.com (Sandra J Loosemore)
- Date: Mon, 17 Oct 88 13:03:38 MDT
This is a new issue, split off from LOAD-TIME-EVAL.
References: CLtL p. 356
Edit History: V1, 17 Oct 1988, Sandra Loosemore
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 all 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
#, is not used very frequently.
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.
In the few places where #, is currently used, some other language
construct such as DEFPARAMETER would have to be used instead. For
... '#,(compute-the-value) ...
could be rewritten as
(defparameter result (compute-the-value))
... result ...
(defparameter result (eval '(compute-the-value)))
... result ...
Issue LOAD-TIME-EVAL proposes to add a special form that would provide
a somewhat cleaner mechanism for doing the same thing (users wouldn't have
to think of a variable name).
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.