Steel Bank Common Lisp

Friedrich Dominicus <frido@...> writes:

> (eq '||:isbn '||::isbn)
>
> debugger invoked on a SB-KERNEL:READER-PACKAGE-ERROR in thread 2198:
>   READER-ERROR on #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {40023161}>:
> package "" not found
>
>
> Not that I found this very readable but one has to use that e.g to use
> cl-xml vom James Anderson.

Then cl-xml should be fixed not to assume that "" is a nickname for
the keyword package.

Cheers,

Christophe

> Then cl-xml should be fixed not to assume that "" is a nickname for
> the keyword package.

But
LispWorks 4.4
(eq '||::isbn '||::isbn)
T

Clisp:
(eq  '||::isbn '||::isbn)
T

Allegro CL 7.0
 (eq '||::isbn '||::isbn)
T

I do not now how this is read by the Reader, just it just give an
error message with SBCL. This is why I asked.

Regards
Friedrich

On Sat, 26 Mar 2005, Friedrich Dominicus wrote:

>> Then cl-xml should be fixed not to assume that "" is a nickname for
>> the keyword package.

> (eq '||::isbn '||::isbn)

> I do not now how this is read by the Reader, just it just give an
> error message with SBCL. This is why I asked.

This is because the implementations you cited have "" as a nickname for 
the KEYWORD package, which is definitely not guaranteed by the standard, 
and possibly forbidden.

Since SBCL doesn't do this, reading the above form signals the error due 
to package "" not existing. So: it's a feature in SBCL and a bug in 
cl-xml.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."

Well I send a few mails to James, just it's not clear to me how it
comes that all the other compilers can cope with it? Well as
understand this should be the same as ::isbn it's not that a " " is
between the | and well according to LW this is interpreted as such

(eq '||::isbn ::isbn)
T

same for CLisp
(eq '||::isbn ::isbn)
T

Allegro:
(eq '||::isbn ::isbn)
T

So I think it's not a feature but bug in how SBCL reads this stuff. 

Regards
Friedrich

On Mar 26, 2005, at 9:05 AM, Friedrich Dominicus wrote:

> Well I send a few mails to James, just it's not clear to me how it
> comes that all the other compilers can cope with it? Well as
> understand this should be the same as ::isbn it's not that a " " is
> between the | and well according to LW this is interpreted as such
>
> (eq '||::isbn ::isbn)
> T
>
> same for CLisp
> (eq '||::isbn ::isbn)
> T
>
> Allegro:
> (eq '||::isbn ::isbn)
> T
>
> So I think it's not a feature but bug in how SBCL reads this stuff.

I would like to believe that you've actually been reading these 
responses and not just hitting "reply" every time a response comes back 
that doesn't say what you were looking for. Indeed, I usually start out 
communication with the belief that the other party wants to gain 
knowledge instead of remaining willfully ignorant. I fear that my 
ability to reconcile your responses with this belief is running out.

Since you appear to be convinced that this is a bug in SBCL itself, 
please point me to chapter and verse in the ANSI specification that 
would indicate that this behavior is mandated. I assume you must have 
good reason for insisting over and over that this is a bug despite the 
responses of people who quite frankly have forgotten more about 
implementing ANSI Common Lisp than you've ever known. If that's the 
case, please tell me what I'm missing. If not, please stop wasting our 
time.
--
Brian Mastenbrook
brian@...
http://www.iscblog.info/

On Mar 26, 2005, at 9:05 AM, Friedrich Dominicus wrote:

> Well as
> understand this should be the same as ::isbn it's not that a " " is
> between the | and well according to LW this is interpreted as such

Just to be completely clear on this Friedrich, please note that 
Nikodemus and Brian have been talking about the empty string, *not* a 
space. In your email quoted above, you're talking about a space, *not* 
the empty string. They are telling you that there is no requirement for 
an implementation to behave as if the empty string is a nickname for 
the keyword package.

All the implementations you quote clearly have readers that  treat the 
empty string as if it were a nickname for the keyword package, so that 
::foo is read as keyword::foo, but they are saying that there is no 
guarantee in the standard that the keyword package have the empty 
string as a nickname, so there is no requirement for implementations to 
read ::foo as if it were keyword::foo. Please not that I am not 
sufficiently familiar with the reader algorithm as given in the 
standard to have any worthwhile opinion on this matter myself.

To see what is going on here is a simple transcript from LispWorks:

CL-USER 11 > (macroexpand keyword::foo)
:FOO
NIL

CL-USER 12 > (macroexpand ::foo)
:FOO
NIL

Interestingly, LispWorks claims that the keyword package has *no* 
nicknames:

CL-USER 20 > (package-nicknames 'keyword)
NIL

Ditto OpenMCL

So technically, this behavior is not due to the keyword package having 
"" as a nickname (because the keyword package has no nicknames in 
LispWorks, ditto OpenMCL). Rather, this behavior must be hard coded 
into their readers.

regards,

Ralph




Raffael Cavallaro, Ph.D.
raffaelcavallaro@...

On Sat, Mar 26, 2005 at 12:03:17PM -0500, Raffael Cavallaro wrote:
> Ditto OpenMCL 
> 
> So technically, this behavior is not due to the keyword package having 
> "" as a nickname (because the keyword package has no nicknames in 
> LispWorks, ditto OpenMCL). Rather, this behavior must be hard coded 
> into their readers. 

Actually OpenMCL behaves just like SBCL here:

| :; openmcl
| Welcome to OpenMCL Version (Beta: Darwin) 0.14.2-p1!
| ? (eq '||::isbn ::isbn)
| 
| > Error in process listener(1): There is no package named "" .
| > While executing: CCL::%COLLECT-XTOKEN
| > Type :GO to continue, :POP to abort.
| > If continued: Retry finding package with name "".
| Type :? for other options.
| 1 >

So it's not like SBCL is the only lisp on the planet that does this.

-bcd
-- 
*** Brian Downing <bdowning at lavos dot net>

Friedrich Dominicus <frido@...> writes:

>> Then cl-xml should be fixed not to assume that "" is a nickname for
>> the keyword package.
>
> But
> LispWorks 4.4
> (eq '||::isbn '||::isbn)
> T
>
> Clisp:
> (eq  '||::isbn '||::isbn)
> T
>
> Allegro CL 7.0
>  (eq '||::isbn '||::isbn)
> T

Why is this relevant?

If you defined a package with name "" in SBCL, you would get the same
effect.  However, SBCL, in its default startup, has no package with
name or nickname "", so the reader cannot access a symbol named by
"ISBN" in the "" package, since there is no package named by "".

Cheers,

Christophe

On Sat, 26 Mar 2005 13:45:04 +0100, Friedrich Dominicus <frido@...> wrote:

> LispWorks 4.4
> (eq '||::isbn '||::isbn)
> T
>
> Clisp:
> (eq  '||::isbn '||::isbn)
> T
>
> Allegro CL 7.0
>  (eq '||::isbn '||::isbn)
> T

I think it is safe to say that at least LispWorks' behaviour is very
questionable in this case:

  CL-USER 1 > (find-package "")
  NIL

  CL-USER 2 > '||:isbn
  :ISBN

  CL-USER 3 > '||::isbn
  :\:ISBN

AllegroCL and CLISP return the keyword package for the first form and
the keyword :ISBN for the other two forms.

Cheers,
Edi.

On Mar 26, 2005, at 2:29 PM, Brian Downing wrote:

> Actually OpenMCL behaves just like SBCL here:

Sorry - must have gotten my various terminal windows confused here.

BTW, (this is for Edi Weitz) LWM errors on this as well - I assume 
you're using LWW in the transcript you showed:

CL-USER 25 > (find-package "")
NIL

CL-USER 26 > '||:isbn
Error: Reader cannot find package .
  1 (continue) Create the  package.
   2 Use another package instead of .
   3 Try finding package  again.
   4 (abort) Return to level 0.
   5 Return to top loop level 0.

Type :b for backtrace, :c <option number> to proceed,  or :? for other 
options

regards

Raffael Cavallaro, Ph.D.
raffaelcavallaro@...

On Sun, 27 Mar 2005 01:01:25 -0500, Raffael Cavallaro <raffaelcavallaro@...> wrote:

> BTW, (this is for Edi Weitz) LWM errors on this as well - I assume
> you're using LWW in the transcript you showed:

Yes.

> CL-USER 25 > (find-package "")
> NIL
>
> CL-USER 26 > '||:isbn
> Error: Reader cannot find package .

Interesting.  I assume you're also using 4.4.[1]  I would have thought
that basic things like this work the same on each platform supported
by LW.

Cheers,
Edi.

[1] Just checked: On Linux I still have 4.3 and it behaves like 4.4 on
    Windows.  Hmm...

On Mar 27, 2005, at 4:20 AM, Edi Weitz wrote:

> Interesting.  I assume you're also using 4.4.[1]  I would have thought
> that basic things like this work the same on each platform supported
> by LW.

Yes, me too. Hence my shedding more heat than light on the situation by 
assuming that Friedrich's  findings were true of LWM as well.

regards,

Ralph

Raffael Cavallaro, Ph.D.
raffaelcavallaro@...

Brian Mastenbrook <brian@...> writes:

> On Mar 26, 2005, at 9:05 AM, Friedrich Dominicus wrote:
>
>> Well I send a few mails to James, just it's not clear to me how it
>> comes that all the other compilers can cope with it? Well as
>> understand this should be the same as ::isbn it's not that a " " is
>> between the | and well according to LW this is interpreted as such
>>
>> (eq '||::isbn ::isbn)
>> T
>>
>> same for CLisp
>> (eq '||::isbn ::isbn)
>> T
>>
>> Allegro:
>> (eq '||::isbn ::isbn)
>> T
>>
>> So I think it's not a feature but bug in how SBCL reads this stuff.
>
> I would like to believe that you've actually been reading these
> responses and not just hitting "reply" every time a response comes
> back that doesn't say what you were looking for. 
Well have I insisted on beeing right? Do I have posted the same over
and over again or do I have put it other things? 




> Since you appear to be convinced that this is a bug in SBCL itself,
> please point me to chapter and verse in the ANSI specification that
> would indicate that this behavior is mandated. I assume you must have
> good reason for insisting over and over that this is a bug despite the
> responses of people who quite frankly have forgotten more about
> implementing ANSI Common Lisp than you've ever known. 
Agreed, I therefor asked how this has to be read. Exactly because I do
read the standard but I understand less about it than I does about
others. 


> If that's the
> case, please tell me what I'm missing. If not, please stop wasting our
> time.
Well probably nothing. 

Friedrich

Nikodemus Siivola <nikodemus@...> writes:

> On Sat, 26 Mar 2005, Friedrich Dominicus wrote:
>
>>> Then cl-xml should be fixed not to assume that "" is a nickname for
>>> the keyword package.
>
>> (eq '||::isbn '||::isbn)
>
>> I do not now how this is read by the Reader, just it just give an
>> error message with SBCL. This is why I asked.
>
> This is because the implementations you cited have "" as a nickname
> for the KEYWORD package, which is definitely not guaranteed by the
> standard, and possibly forbidden.
>
> Since SBCL doesn't do this, reading the above form signals the error
> due to package "" not existing. So: it's a feature in SBCL and a bug
> in cl-xml.

Hmmm. I'm not sure I buy that--per Section 2.2 Reader Algorithm it
seems to me that reading the following two sequences of characters

  ::isbn
  ||::isbn

should be read the same as tokens, regardless of whether "" is a
nickname for the keyword package. Here's my reasoning:

  - Start in step 1. Not at end of file so go to Step 7 because #\: is
    a constituent character.
 
  - In Step 7 begin reading a token with #\: as the first character. Go
    to step 8.

  - In Step 8 loop collecting the characters #\:, #\i, #\s, #\b, and
    #\n. When we read the whitespace or terminating macro character
    after #\b go to Step 10 where the token is converted to an object.

To read ||::isbn we follow a slightly different path but with the same
resulting token.

  - Start in step 1. Not at end of file so go to Step 9 because #\| is
    a multiple escape character.
 
  - In Step 9, read the next character, a #\| and go to Step 8.

  - In Step 8 loop collecting the characters #\:, #\:, #\i, #\s, #\b,
    and #\n. When we read the whitespace or terminating macro
    character after #\b goto Step 10.

In Step 10 the token token "::isbn" is converted to an object.
However, according to the rules in 2.3.5, "::aaaa" is an undefined
pattern for the name of a symbol so SBCL can legitimately signal an
error.

However SBCL (0.8.16 anyway) signals an error when reading ||:isbn
which seems wrong according to Sections 2.2 and 2.3.5. So if CL-XML
really contains tokens written as either ||::isbn *or* ::isbn it is a
bug in CL-XML. But if CL-XML contains ||:isbn, I'd say that SBCL is
wrong to signal an error when reading those tokens. Or maybe I'm
missing something.

-Peter

-- 
Peter Seibel                                     peter@...

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

[Apologies if this shows up twice--I first tried to post via Gmane and
after a half-day it hasn't shown up either on Gmane or on the list.]

Nikodemus Siivola <nikodemus@...> writes:

> On Sat, 26 Mar 2005, Friedrich Dominicus wrote:
>
>>> Then cl-xml should be fixed not to assume that "" is a nickname for
>>> the keyword package.
>
>> (eq '||::isbn '||::isbn)
>
>> I do not now how this is read by the Reader, just it just give an
>> error message with SBCL. This is why I asked.
>
> This is because the implementations you cited have "" as a nickname
> for the KEYWORD package, which is definitely not guaranteed by the
> standard, and possibly forbidden.
>
> Since SBCL doesn't do this, reading the above form signals the error
> due to package "" not existing. So: it's a feature in SBCL and a bug
> in cl-xml.

Hmmm. I'm not sure I buy that--per Section 2.2 Reader Algorithm it
seems to me that reading the following two sequences of characters

  ::isbn
  ||::isbn

should be read the same as tokens, regardless of whether "" is a
nickname for the keyword package. Here's my reasoning:

  - Start in step 1. Not at end of file so go to Step 7 because #\: is
    a constituent character.
 
  - In Step 7 begin reading a token with #\: as the first character. Go
    to step 8.

  - In Step 8 loop collecting the characters #\:, #\i, #\s, #\b, and
    #\n. When we read the whitespace or terminating macro character
    after #\b go to Step 10 where the token is converted to an object.

To read ||::isbn we follow a slightly different path but with the same
resulting token.

  - Start in step 1. Not at end of file so go to Step 9 because #\| is
    a multiple escape character.
 
  - In Step 9, read the next character, a #\| and go to Step 8.

  - In Step 8 loop collecting the characters #\:, #\:, #\i, #\s, #\b,
    and #\n. When we read the whitespace or terminating macro
    character after #\b goto Step 10.

In Step 10 the token token "::isbn" is converted to an object.
However, according to the rules in 2.3.5, "::aaaa" is an undefined
pattern for the name of a symbol so SBCL can legitimately signal an
error.

However SBCL (0.8.16 anyway) signals an error when reading ||:isbn
which seems wrong according to Sections 2.2 and 2.3.5. So if CL-XML
really contains tokens written as either ||::isbn *or* ::isbn it is a
bug in CL-XML. But if CL-XML contains ||:isbn, I'd say that SBCL is
wrong to signal an error when reading those tokens. Or maybe I'm
missing something.

-Peter

-- 
Peter Seibel                                     peter@...

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

On Mar 30, 2005, at 8:26 PM, Peter Seibel wrote:

> However SBCL (0.8.16 anyway) signals an error when reading ||:isbn
> which seems wrong according to Sections 2.2 and 2.3.5. So if CL-XML
> really contains tokens written as either ||::isbn *or* ::isbn it is a
> bug in CL-XML. But if CL-XML contains ||:isbn, I'd say that SBCL is
> wrong to signal an error when reading those tokens. Or maybe I'm
> missing something.

Hi Peter,

I think you are. SBCL does not unconditionally signal an error when 
reading '||::sbcl. It only signals an error when there is no package 
named by "".

* '||::sbcl

debugger invoked on a SB-KERNEL:READER-PACKAGE-ERROR in thread 19004:
   READER-ERROR at 434 on #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* 
{8011139}>:
package "" not found

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
   0: [ABORT] Exit debugger, returning to top level.

(SB-IMPL::READ-TOKEN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {8011139}> 
#\|)
0] 0

* (defpackage "")

#<PACKAGE "">
* '||::sbcl

||::SBCL
*
--
Brian Mastenbrook
brian@...
http://www.iscblog.info/

Brian Mastenbrook <brian@...> writes:

> On Mar 30, 2005, at 8:26 PM, Peter Seibel wrote:
>
>> However SBCL (0.8.16 anyway) signals an error when reading ||:isbn
>> which seems wrong according to Sections 2.2 and 2.3.5. So if CL-XML
>> really contains tokens written as either ||::isbn *or* ::isbn it is a
>> bug in CL-XML. But if CL-XML contains ||:isbn, I'd say that SBCL is
>> wrong to signal an error when reading those tokens. Or maybe I'm
>> missing something.
>
> Hi Peter,
>
> I think you are. SBCL does not unconditionally signal an error when
> reading '||::sbcl. It only signals an error when there is no package
> named by "".

Yes, but... this might just be wrong.  That is, 2.3.5 suggests that
||:sbcl, which by 2.2 and Peter's argument is the same as :sbcl,
should be interpreted as a symbol in the keyword package, independent
of whether there's a "" package or not.  (And the corollary is that
there is no reader syntax for symbols in the "" package, if that's
distinct from the KEYWORD package, other than #.(intern "FOO" "").)

This is not a difficult change to make, and I suspect that Peter might
be right in his reading, but do you (collectively) mind if we wait for
Paul Dietz to return from his travels, for a fourth opinion?

Cheers, 

Christophe

Christophe Rhodes <csr21 <at> cam.ac.uk> writes:

> Yes, but... this might just be wrong.  That is, 2.3.5 suggests that
> ||:sbcl, which by 2.2 and Peter's argument is the same as :sbcl,
> should be interpreted as a symbol in the keyword package, independent
> of whether there's a "" package or not.  (And the corollary is that
> there is no reader syntax for symbols in the "" package, if that's
> distinct from the KEYWORD package, other than #.(intern "FOO" "").)
> 
> This is not a difficult change to make, and I suspect that Peter might
> be right in his reading, but do you (collectively) mind if we wait for
> Paul Dietz to return from his travels, for a fourth opinion?

I think Peter is right too, so ||:foo is working on LWW but not on LWM.  For
||::foo, you get what you deserve...

__Martin