Is there any CL impl where :... is not recognized as a
keyword? The standard leaves this decision to the
impl.
CLISP, for instance, accepts :... although it considers
... to be an invalid symbol, because the CL
standard classifies ... as a "potential number"
(how??!!!).
····@goldshoe.gte.com (Dorai Sitaram) writes:
> Is there any CL impl where :... is not recognized as a
> keyword? The standard leaves this decision to the
> impl.
>
> CLISP, for instance, accepts :... although it considers
> ... to be an invalid symbol, because the CL
> standard classifies ... as a "potential number"
> (how??!!!).
There was a lot of fussing about potential numbers a while back with
overzealous implementations doing people the favor of signaling errors.
Implementations apparently disagree on this, and there's nothing you
can do formally about this. What follows is my personal opinion about
the right way to read the stuff on potential numbers.
I don't recall anyone wanting to stop people from using certain symbols.
Rather, the spec wanted to reserve to vendors the right to experiment
with new number syntaxes. Therefore, it was thought to be the conservative
programming style that if you didn't use the potential numbers, you wouldn't
have to worry that your symbols weren't symbols in some implementation.
Some people interpreted this to mean that 3600 [the model number of some
lisp machines] was a number but that :3600 was a symbol. This created a
lot of confusion about whether you had to write #+:3600 in order to make
sure you meant a symbol, and a lot of people inserted colons there because
they were afraid otherwise it wouldn't be a symbol. This was a big laugh
because on the 3600, :3600 was read as an integer just like 3600, so it
didn't turn out to matter. And on non-3600's, neither 3600 nor :|3600|
were in *features* so things failed anyway. So it was just a lot of fussing
for nothing. [It was important to know that 3600, not :|3600| was what
was in the *features* list if you used MEMBER explicitly, as some did.]
Anyway, it seems to be the case that no one has actually extended the number
syntax in some of the ways expected. So everyone who protects people from
potential number is (so far) protecting them from nothing. This doesn't
mean there will never be a future problem, but I personaly think it's not
fair to restrict people from using perfectly good symbols now. Instead,
I think people should use #-/#+ in the future if/when they need to.
EVEN THEN, if such conditionals are to work, they need to read without
error and the only thing that should happen is that you don't know if it will
be a number or a symbol. Otherwise, the tokenizer can't skip the expression
that is conditionalized out.
So, IMO, it would be best if potential numbers were just things for which you
don't know whether (read-from-string "..potential_number_syntax..") will
yield a number or a symbol.
I think that notwithstanding the potential number stuff, unless _that
very implementation_ wants to grab the syntax itself and _define_ it as a
number, then it should just make it a symbol. This is the course of least
resistance that will make the user community happy. There just isn't any
use in reserving things out of paranoia.
Same with the # dispatch characters that are reserved to implementations
instead of users. Yes, users could get in trouble for grabbing them, but if
implementations haven't grabbed them, or if the user isn't using what the
implementation offers, there's no real harm, and signaling an error would
be just annoying to no good end.
These are just my personal opinions. A conservative reading of the spec
would say you should not use things that are in the gray area, and I can't
say that an implementation that steals this stuff from you is definitely
wrong. I can just say _I_ would send a bug report. ;)
····@goldshoe.gte.com (Dorai Sitaram) writes:
> Is there any CL impl where :... is not recognized as a
> keyword? The standard leaves this decision to the
> impl.
>
> CLISP, for instance, accepts :... although it considers
> ... to be an invalid symbol, because the CL
> standard classifies ... as a "potential number"
> (how??!!!).
I agree with Kent about not signalling errors on reading potential
numbers, but it turns out to irrelevant in this case, because ... is
not a potential number! It fails requirement 2 in ANS 2.3.1.1.
However, ... is an invalid _token_, by ANS 2.3.3 which requires that
an error is signalled if a token consists solely of dots. However,
:... is not an invalid token.
So, :... should be OK in any implementation - just don't set current
package to "KEYWORD" and try to input it as ...!
--
Pekka P. Pirinen
Don't pay for junk email. It's your private mailbox, and they're abusing
it. If you don't complain, they'll do it again. Don't hit delete, get
*them* deleted. See <http://www.uk.spam.abuse.net/spam/> for info.
···············@globalgraphics.com (Pekka P. Pirinen) writes:
> ····@goldshoe.gte.com (Dorai Sitaram) writes:
> > Is there any CL impl where :... is not recognized as a
> > keyword? The standard leaves this decision to the
> > impl.
> >
> > CLISP, for instance, accepts :... although it considers
> > ... to be an invalid symbol, because the CL
> > standard classifies ... as a "potential number"
> > (how??!!!).
>
> I agree with Kent about not signalling errors on reading potential
> numbers, but it turns out to irrelevant in this case, because ... is
> not a potential number! It fails requirement 2 in ANS 2.3.1.1.
>
> However, ... is an invalid _token_, by ANS 2.3.3 which requires that
> an error is signalled if a token consists solely of dots.
Oh, right... Hmm.
Well, now that I think of it, I think this is maybe so that an
abbreviated form like (foo ...) from *print-length* abbreviation
won't try to re-read.
> However,
> :... is not an invalid token.
>
> So, :... should be OK in any implementation - just don't set current
> package to "KEYWORD" and try to input it as ...!
Heh. I guess it's protecting you by assuring that:
(let ((*package* (find-package "KEYWORD")))
(let ((*print-circle* nil) ; Don't look for circular lists
(*print-length* 3)) ; ... but protect against "long" ones!
(let* ((x (list :foo))
(xtr (prin1-to-string (nconc x x))))
(list (list :foo :foo :foo :...)
(handler-case (read-from-string xtr)
(error (c) (list xtr (princ-to-string c))))))))
=> ((:FOO :FOO :FOO :|...|)
("(:FOO :FOO :FOO ...)" "A token cannot consist of dots only: \"...\"."))
[I did this in LW, which seems to print keywords as :FOO even when
*PACKAGE* is the keyword package.]
In article <·············@globalgraphics.com>,
Pekka P. Pirinen <···············@globalgraphics.com> wrote:
>····@goldshoe.gte.com (Dorai Sitaram) writes:
>> Is there any CL impl where :... is not recognized as a
>> keyword? The standard leaves this decision to the
>> impl.
>>
>> CLISP, for instance, accepts :... although it considers
>> ... to be an invalid symbol, because the CL
>> standard classifies ... as a "potential number"
>> (how??!!!).
>
>I agree with Kent about not signalling errors on reading potential
>numbers, but it turns out to irrelevant in this case, because ... is
>not a potential number! It fails requirement 2 in ANS 2.3.1.1.
>
>However, ... is an invalid _token_, by ANS 2.3.3 which requires that
>an error is signalled if a token consists solely of dots. However,
>:... is not an invalid token.
>
>So, :... should be OK in any implementation - just don't set current
>package to "KEYWORD" and try to input it as ...!
This being cll, I am forced to ask for
clarification: How strong is the "should"? Can I
replace it with "will"?
Is it possible for a CL impl to legitimately
claim to be ANSI-compliant and yet not treat :... as a
valid token?
····@goldshoe.gte.com (Dorai Sitaram) writes:
> In article <·············@globalgraphics.com>,
> Pekka P. Pirinen <···············@globalgraphics.com> wrote:
> ...
> >I agree with Kent about not signalling errors on reading potential
> >numbers, but it turns out to irrelevant in this case, because ... is
> >not a potential number! It fails requirement 2 in ANS 2.3.1.1.
> >
> >However, ... is an invalid _token_, by ANS 2.3.3 which requires that
> >an error is signalled if a token consists solely of dots. However,
> >:... is not an invalid token.
> >
> >So, :... should be OK in any implementation - just don't set current
> >package to "KEYWORD" and try to input it as ...!
>
> This being cll, I am forced to ask for
> clarification: How strong is the "should"? Can I
> replace it with "will"?
Well, the "should" you're asking about is a "should" in a piece of
netnews, not a "should" in the ANSI CL spec. I don't see any "should"
there in the spec. So first, I recommend you take this entire discussion
as "food for thought" and then go to your primary reference and see if
you don't agree.
It seems to ME that...
It's clear that Pekka is right, point 2 of 2.3.1.1 is not satisfied by
"..." so "..." is not a potential number.
It's further clear in 2.3.3 as Pekka notes that an error "is signaled"
(not "might be" or any of its variants) for any number of dots but one.
> Is it possible for a CL impl to legitimately
> claim to be ANSI-compliant and yet not treat :... as a
> valid token?
Given that "..." is not a potential number, and given ":..." isn't all
dots, I don't see any way to be conforming and not reliably read :...
as a symbol.
THAT SAID, I don't think you should assume that all implementations are
bug-free or that all vendors agree on the reading of all documentation.
If you're asking what you should do as a _programmer_, I'll give you
different advice than as a _vendor_. I think vendors should fix their
implementations. But I think that since this is a known to be
troublesome point, it's worth programmers moving carefully in this
area.