[Openmcl-devel] "potential numbers" as symbol names
helink at sandia.gov
Wed Apr 20 22:12:42 UTC 2005
... with apologies to Mr. Knapp for turning his email upside down ...
On Apr 20, 2005, at 1:43 PM, Dan Knapp wrote:
> Now that I've worked all that out, I guess I don't much care either
> way. :)
> It comes down to whether it's better to tolerate marginal behaviour,
> or to
> "soundly trounce" it.
I think tolerating marginal behavior lets programmers fool themselves
into thinking their code is more portable than it is, and I've been
fooled enough times by tolerant lisps (fooled, up until I tried to
argue something's portability with Foderaro and have been pointed to
obscure passages in cleanup issues or the hyperspec) to feel that early
trouncing is probably the better path.
> So we're left with two interpretations. Either :3 is a token and a
> with cautionary wording in a couple places that it really isn't, or
> undefined whether :3 is a token at all.
I think the safe bet is to say that :3 isn't a valid token and error,
because it could be justifiably interpreted in several different ways
if it was, and as a case in point different modern implementations were
seemingly interpreting it in different ways at the time of X3J13,
leading up to the cleanup issue.
The rest of this email is just me being pedantic, please skip it. I
can't help it sometimes (just ask my wife, it drives her nuts).
> At first I thought that this was perfectly well-defined. Remember
> a token is a "textual representation" (glossary), not an actual symbol
Yeah, I was being sloppy in my prose when I said \3 was a legit symbol
and :3 was not. What I should have said is that \3 is a token that
unambiguously is supposed to resolve into a symbol when read (and :3
To me (although I don't matter) the package qualifier is sort-of just
there to make sure the reader adjusts its view of the current package
when reading a particular token. It's supposed to be essentially the
same thing as saying
(let ((*package* (find-package package-part)))
If you buy that, it's sensible to think of cl-user:4 as a number,
because the token 4 after an (in-package :cl-user) is a number. So
would be 4 after an (in-package :keyword). So for numbers should any
hinky package qualifier matter, and prevent potential-numberness, or
To some degree it's sophistry to argue one way or the other this late
in the game, since someone closer to the issue has already suggested it
be deemed not well defined.
> Section 2.3.4 seems to say...
> 2.3.5 is somewhat ambiguous...
> If so, this is directly at odds
> with 2.3.4, which does define its interpretation.
This is possibly why the cleanup issue is there.
> However, if :3 is not a
> token at all, there is no conflict, because 2.3.4 describes rules for
> interpretation of tokens.
> If :3 were considered a token, it would be a symbol. It is not a
> potential number as defined by 184.108.40.206 (clause 1), because it contains
> a character which is not a digit, number marker, etc (section 220.127.116.11,
> "Character Traits").
Well, |:3| is a symbol, but the corresponding token isn't :3, it's \:3
or |:3|. And the token for the symbol whose pname is "3" is \3 or |3|,
so :3 isn't a portable printable representation for anything that you'd
put in the keyword package, while :\3 is. This picky bit might be part
of why the definition of token ended up a little imprecise. Is ':a' a
token, or is the token 'a' and the rest just an indication the token
should be read within the keyword package?
Given what I interpret package qualifiers to mean, :3 isn't a valid
token imho, and conveniently for mho that means you can set the current
package, strip off package qualifiers, and read some unknown thing
without the result flip-flopping between a number and a symbol.
Similarly you can't tack a package qualifier onto just any
readably-printable thing and expect to get back what you started with
when you run READ on it (which, if :3 didn't error, might silently give
you back something of a different type).
> Another minor point: It's incorrect to say that "\3" is a legit
> symbol while
> "3" is not. Both are valid as symbol names in the sense that you can
> INTERN on those strings directly (and they are two different symbols).
> The question is only whether :3 and package:3 are tokens which are to
> interpreted as symbols.
Well, since we're talking about the reader it's not fair to use quotes.
\\3 and \3 are two different symbols, yes.
Anyhow, given all this hullaballoo, I think in cl-photo's case it's a
bug in cl-photo to not escape 3 when it's meant to be read as a symbol,
although it's on a technicality.
More information about the Openmcl-devel