From: Friedrich D. <fr...@q-...> - 2005-03-25 10:20:07
|
Ok, a point in which SBCL does not work as e.g CLisp or LispWorks: (eq '||::isbn '||::isbn) LW output T Clisp output T SBCL (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. Regards Friedrich |
From: Christophe R. <cs...@ca...> - 2005-03-25 10:31:24
|
Friedrich Dominicus <fr...@q-...> 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 |
From: Friedrich D. <fr...@q-...> - 2005-03-26 12:46:45
|
> 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 |
From: Nikodemus S. <nik...@ra...> - 2005-03-26 13:00:20
|
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." |
From: Friedrich D. <fr...@q-...> - 2005-03-26 15:06:35
|
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 |
From: Peter S. <pe...@gi...> - 2005-03-31 05:40:07
|
[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 <nik...@ra...> 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 pe...@gi... Lisp is the red pill. -- John Fraser, comp.lang.lisp |
From: Brian M. <br...@ma...> - 2005-03-31 13:50:41
|
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 br...@ma... http://www.iscblog.info/ |
From: Christophe R. <cs...@ca...> - 2005-03-31 14:25:32
|
Brian Mastenbrook <br...@ma...> 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 |
From: Martin S. <ma...@li...> - 2005-03-31 21:52:32
|
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 |
From: Christophe R. <cs...@ca...> - 2005-03-26 20:54:14
|
Friedrich Dominicus <fr...@q-...> 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 |
From: Edi W. <ed...@ag...> - 2005-03-26 21:24:46
|
On Sat, 26 Mar 2005 13:45:04 +0100, Friedrich Dominicus <fr...@q-...> 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. |
From: Brian M. <br...@ma...> - 2005-03-26 16:23:16
|
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 br...@ma... http://www.iscblog.info/ |
From: Raffael C. <raf...@ma...> - 2005-03-26 17:03:25
|
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. raf...@ma... |
From: Brian D. <bdo...@la...> - 2005-03-26 19:30:04
|
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> |
From: Raffael C. <raf...@ma...> - 2005-03-27 06:01:34
|
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. raf...@ma... |
From: Edi W. <ed...@ag...> - 2005-03-27 09:20:31
|
On Sun, 27 Mar 2005 01:01:25 -0500, Raffael Cavallaro <raf...@ma...> 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... |
From: Raffael C. <raf...@ma...> - 2005-03-27 14:39:59
|
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. raf...@ma... |
From: Friedrich D. <fr...@q-...> - 2005-03-30 06:46:38
|
Brian Mastenbrook <br...@ma...> 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 |
From: Peter S. <pe...@gi...> - 2005-03-30 19:52:51
|
Nikodemus Siivola <nik...@ra...> 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 pe...@gi... Lisp is the red pill. -- John Fraser, comp.lang.lisp |