[Openmcl-devel] "potential numbers" as symbol names

[Gary Byers]

On Wed, 20 Apr 2005, bryan o'connor wrote:

> first of all, i talked to kmr and he is going to escape
> the offending items.
>
> given that and this thread, i'm leaning back towards the
> error case.  but with a more descriptive error message
> stating that :1 is undefined behavior and what you probably
> want is :\1.
>
> i'm ok with the idea of openmcl being less "tolerant of
> marginal behavior" as long as it helps the user with an
> informative error message.
>
>   ...bryan
>

What I recall of the context of the cleanup issue (and the decision to
leave this case as "explicitly vague") is that some lisps used :NNNN
(where NNNN is a "potential number" and not escaped) in break loop
commmands (e.g., for choosing restarts) and that CLtL[1|2] considered
this to be invalid syntax and may have required that an error be
signaled when it was encountered (I don't remember for sure whether
this requirement existed).  Outside of that limited context
(break-loop commands), I'm not sure that anyone ever argued that
allowing [PACKAGE}:NNNN was particularly useful, and it kind of
destroys the model that PACKAGE[:]:XXXX is shorthand for something
like

 (let ((*package* (find-package "PACKAGE")))
   (read))  ; well, not exactly, but it's maybe a helpful model

I don't think that anyone felt that -allowing- :NNNN was so horrific
that vendors who did so should have to change their implementations,
(and re-write their documentation, and require their users to change
their habits ...), and I don't think that anyone felt that allowing
:NNNN in a break loop was such a big UI win that it should be required
behavior, so the cleanup committee settled on leaving the behavior
unspecified.

Flash forward to 2005, and I would guess that OpenMCL (and probably
commercial MCL) represent the minority in signaling an error in this
case.  When I saw Bryan's patch ("joining the majority"), my first
reaction was to think "Thanks! That'll mean fewer reports that
'CL-PHOTO doesn't work with OpenMCL'."  That -is- admittedly an
"enabling" reaction (we become codependents of would-be potential-
number syntax abusers), but the issue is obscure and murky and
confusing enough that that benefit can't be entirely discounted.

Claiming that :NNNN is "Illegal symbol syntax" is certainly
somewhat inaccurate (the spec doesn't define this to be illegal),
and being slightly more accurate in the error message ("Ambiguous
symbol syntax, see CLHS 2.3.1.1, paragraph 3") might or might not
be less confusing.

The primary reason that I can think of for -not- becoming a
codependent, enabling member of the majority is that the
not-quite-accurate-but- generally-useful model of the how package
qualifiers affect the reader becomes invalid (what happens when READ
encounters a potential number with *PACKAGE* bound is different from
what happens when PACKAGE[:]:NNNN is encountered.)  (The other reason
- discouraging the user from depending on non-standard and potentially
non-portable behavior - seems a little less compelling; carried to
extremes, the implemenation would warn or error every time a thread
was created or a foreign function was called ...)

I don't think that there's any issue of standards compliance here
(since 2.3.1.1 paragraph 3 leaves this situation unspecified.)  If
this issue came up more often - or if authors of programs that
depended on non-portable behavior were reluctant to change those
programs - I think that I'd find that Bryan's original fix
(interpreting this case in an occasionally useful if somewhat
funky way) has greater overall benefit than signaling an error
(refusing to even deal with a murky, unspecified case that may
very well be the result of a typo.)

The decision of what to do here doesn't (I don't think) affect
performance much in cases where errors aren't signaled (we currently
try to compute the numeric value of a "potential number" - partly as
a way of discovering that we have a potential number token - before
we do anything else, so things like:

:1/0

error out even with Bryan's original change.  If we deferred that
until later if package qualifiers were present, it might make this
case a little faster, but this is a pretty obscure case ...)

Since there don't seem to be too many (otherwise) portable programs
out there that depend on certain non-error behavior being attached
to the :NNNN case (and since Kevin was willing to change CL-PHOTO
to not do so), I think that "old behavior with better error message"
would also be a reasonable resolution.