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

[Hamilton Link]

... 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 
> symbol,
> with cautionary wording in a couple places that it really isn't, or 
> it's
> 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).

thanks,
h

>  At first I thought that this was perfectly well-defined.  Remember 
> that
> a token is a "textual representation" (glossary), not an actual symbol 
> or
> number.

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 
isn't unambiguous).

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)))
   (read-from-string the-rest))

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 
not?

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 
> the
> interpretation of tokens.
>
>   If :3 were considered a token, it would be a symbol.  It is not a
> potential number as defined by 2.3.1.1 (clause 1), because it contains
> a character which is not a digit, number marker, etc (section 2.1.4.2,
> "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 
> 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.

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.