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

[bryan o'connor]

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


On Apr 20, 2005, at 15.12, Hamilton Link wrote:

> ... 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.
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>