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

[Dan Knapp]

> 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 
important
point in the discussion.  Now I will go on and disagree with some of 
what you
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 
token is
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
token.

   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 
determine it.

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

   Good point.

>>   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 
>> call
>> 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 
textual
entities.  I should've been more explicit.

-- Dan Knapp