[Openmcl-devel] "potential numbers" as symbol names
dankna at accela.net
Wed Apr 20 19:10:48 EDT 2005
> 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.
Let me begin by saying that I agree with this, which is the only
point in the discussion. Now I will go on and disagree with some of
say further down, 'cause you got me interested. :)
> 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.
I also agree with this. Okay, two important points.
> 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
A reasonable view, but not what the standard says.
> 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?
This is why I pointed out that a token is not a symbol or number. A
the *unparsed* text. The reader algorithm, described in S2.2, finds the
longest contiguous sequence of constituent characters and nonterminating
macro characters, and : is a constituent character; therefore it is
part of the
So, it is definitely well-defined what the token would be if in fact
it were a
token. Can't get much more explicit than giving an algorithm to
> 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 be
>> 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.
Yeah; I was just trying to emphasize the unparsed nature of these
entities. I should've been more explicit.
-- Dan Knapp
More information about the Openmcl-devel