From: Sam S. <sd...@gn...> - 2003-03-27 16:21:12
|
> * In message <Pin...@as...> > * On the subject of "Re: New patch." > * Sent on Thu, 27 Mar 2003 07:27:39 -0800 (PST) > * Honorable Kaz Kylheku <ka...@as...> writes: > > http://users.footprints.net/~kaz/clisp-cvs-2003-04-26-backquote.diff read-from-string "`,@x") -ERROR +(SYSTEM::BACKQUOTE (SYSTEM::SPLICE X)) this is not good: backquote is a reader macro, so the error must be signalled at read time, not macroexpand time (CMUCL and unpatched CLISP signal at read time). -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Those who can laugh at themselves will never cease to be amused. |
From: Kaz K. <ka...@as...> - 2003-03-27 18:24:49
|
On 27 Mar 2003, Sam Steingold wrote: > > * In message <Pin...@as...> > > * On the subject of "Re: New patch." > > * Sent on Thu, 27 Mar 2003 07:27:39 -0800 (PST) > > * Honorable Kaz Kylheku <ka...@as...> writes: > > > > http://users.footprints.net/~kaz/clisp-cvs-2003-04-26-backquote.diff > > read-from-string "`,@x") > -ERROR > +(SYSTEM::BACKQUOTE (SYSTEM::SPLICE X)) > > this is not good: backquote is a reader macro, so the error must be > signalled at read time, not macroexpand time (CMUCL and unpatched CLISP > signal at read time). If you are really adamant about catching `,@FORM at read time, it can be achieved trivially. After the the backquote reader reads the following object, if it's a cons whose car is the symbol SYSTEM::SPLICE or SYSTEM::NSPLICE, then signal the error. But I think that the macro-expansion-time check should stay in place, to trap cases when the error occurs in ``synthetic'' backquotes. CLHS says that `,@FORM ``has undefined consequences'', which means that the behavior can range from harmless to fatal, without signaling an error. So I think this implementation is acceptable. In principle we could even silently provide some extension of behavior. In practice, will the difference matter to anyone? Typically the backquote macro will be expanded at compile time, which is right after the source is read. It makes a difference to backquotes that are not evaluates or expanded, such as quoted occurences. This just means that CLISP won't be a portability helper to the user in some rare cases. Besides, both the unpatched CLISP and CMUCL have backquote bugs, so phwft! :) I got this in an e-mail from Rob Warnock, though I did not try it first hand: cmucl> ``(,@,@'(a b c d)) Reader error at 202581 on #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>>: ,@ after backquote in '(A B C D) Looks like the CMUCL reader likes to signal a ``,@ after backquote'' error even when no such mistake occurs in the source, and consequently fails to handle ,@,@ properly! Maybe if I ever fix this bug, the CMUCL behavior will change so that `,@FORM is caught later than read time. ;) |
From: Sam S. <sd...@gn...> - 2003-03-27 19:49:11
|
> * In message <Pin...@as...> > * On the subject of "Re: New patch." > * Sent on Thu, 27 Mar 2003 10:23:48 -0800 (PST) > * Honorable Kaz Kylheku <ka...@as...> writes: > > On 27 Mar 2003, Sam Steingold wrote: > > > * Honorable Kaz Kylheku <ka...@as...> writes: > > > > > > http://users.footprints.net/~kaz/clisp-cvs-2003-04-26-backquote.diff > > > > read-from-string "`,@x") > > -ERROR > > +(SYSTEM::BACKQUOTE (SYSTEM::SPLICE X)) > > > > this is not good: backquote is a reader macro, so the error must be > > signalled at read time, not macroexpand time (CMUCL and unpatched CLISP > > signal at read time). > > If you are really adamant about catching `,@FORM at read time, > it can be achieved trivially. After the the backquote reader > reads the following object, if it's a cons whose car is the symbol > SYSTEM::SPLICE or SYSTEM::NSPLICE, then signal the error. > But I think that the macro-expansion-time check should stay in place, > to trap cases when the error occurs in ``synthetic'' backquotes. maybe the BACKQUOTE macro should be expanded at read time, just like CLISP does right now. > CLHS says that `,@FORM ``has undefined consequences'', which means > that the behavior can range from harmless to fatal, without signaling > an error. So I think this implementation is acceptable. In principle > we could even silently provide some extension of behavior. CLISP usually signals an error in "undefined consequences". > In practice, will the difference matter to anyone? Typically the > backquote macro will be expanded at compile time, which is right > after the source is read. the earlier you detect errors the better, right? > It makes a difference to backquotes that are not evaluates or expanded, > such as quoted occurences. This just means that CLISP won't be a > portability helper to the user in some rare cases. why? if CLISP detects errors earlier than it has to, it's good! > Besides, both the unpatched CLISP and CMUCL have backquote bugs I think the new BQ should improve in all areas. removing some bugs (improving!) and moving error detection to a later time (deterioration?) is not nice. I am not really sure on this, so maybe you could raise this issue on c.l.l? thanks! -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> When we break the law, they fine us, when we comply, they tax us. |
From: Kaz K. <ka...@as...> - 2003-03-27 20:14:43
|
On 27 Mar 2003, Sam Steingold wrote: > > On 27 Mar 2003, Sam Steingold wrote: > > > > * Honorable Kaz Kylheku <ka...@as...> writes: > > > > > > > > http://users.footprints.net/~kaz/clisp-cvs-2003-04-26-backquote.diff > > > > > > read-from-string "`,@x") > > > -ERROR > > > +(SYSTEM::BACKQUOTE (SYSTEM::SPLICE X)) > > > > > > this is not good: backquote is a reader macro, so the error must be > > > signalled at read time, not macroexpand time (CMUCL and unpatched CLISP > > > signal at read time). > > > > If you are really adamant about catching `,@FORM at read time, > > it can be achieved trivially. After the the backquote reader > > reads the following object, if it's a cons whose car is the symbol > > SYSTEM::SPLICE or SYSTEM::NSPLICE, then signal the error. > > But I think that the macro-expansion-time check should stay in place, > > to trap cases when the error occurs in ``synthetic'' backquotes. > > maybe the BACKQUOTE macro should be expanded at read time, just like > CLISP does right now. You just need something like this version of backquote-reader: (defun backquote-reader (stream char) (declare (ignore char)) (let* ((*unquote-occured* nil) (*reading-array* nil) (*backquote-level* (1+ (or *backquote-level* 0))) (object (read stream t nil t))) ;; Check for unquotes in wrong type objects. (unless (or (and (vectorp object) (not (stringp object)) (not (bit-vector-p object))) (listp object)) (when *unquote-occured* (error-of-type 'error (TEXT "~S: unquotes may occur only in (...) or #(...) forms") 'read))) ;; Read-time check for ,@ or ,. not in list. ;; Also tested at macro-expansion time for ;; backquotes synthesized by means other than the reader (when (consp object) (case (car object) ((SPLICE) (error-of-type 'error (TEXT "the syntax `,@form is undefined behavior"))) ((NSPLICE) (error-of-type 'error (TEXT "the syntax `,.form is undefined behavior"))))) (list 'BACKQUOTE object))) > I am not really sure on this, so maybe you could raise this issue on > c.l.l? What for; it's clear you want early detection. On c.l.l, people will probably just reiterate that it's undefined behavior, but that catching errors early is nice. ;) |
From: Sam S. <sd...@gn...> - 2003-03-27 23:42:18
|
> * In message <Pin...@as...> > * On the subject of "Re: New patch." > * Sent on Thu, 27 Mar 2003 12:13:41 -0800 (PST) > * Honorable Kaz Kylheku <ka...@as...> writes: > > (defun backquote-reader (stream char) > (declare (ignore char)) > (let* ((*unquote-occured* nil) > (*reading-array* nil) > (*backquote-level* (1+ (or *backquote-level* 0))) > (object (read stream t nil t))) > > ;; Check for unquotes in wrong type objects. > (unless (or (and (vectorp object) > (not (stringp object)) > (not (bit-vector-p object))) > (listp object)) > (when *unquote-occured* > (error-of-type 'error > (TEXT "~S: unquotes may occur only in (...) or #(...) forms") > 'read))) what if we had something like `(foo #2A((a b) (,c d))) ?? > ;; Read-time check for ,@ or ,. not in list. > ;; Also tested at macro-expansion time for > ;; backquotes synthesized by means other than the reader > (when (consp object) > (case (car object) > ((SPLICE) > (error-of-type 'error > (TEXT "the syntax `,@form is undefined behavior"))) > ((NSPLICE) > (error-of-type 'error > (TEXT "the syntax `,.form is undefined behavior"))))) > (list 'BACKQUOTE object))) > > > I am not really sure on this, so maybe you could raise this issue on > > c.l.l? > > What for; it's clear you want early detection. On c.l.l, people will > probably just reiterate that it's undefined behavior, but that catching > errors early is nice. ;) you never know, we may hear some additional insight! -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Any programming language is at its best before it is implemented and used. |
From: Kaz K. <ka...@as...> - 2003-03-28 00:48:55
|
On 27 Mar 2003, Sam Steingold wrote: > > ;; Check for unquotes in wrong type objects. > > (unless (or (and (vectorp object) > > (not (stringp object)) > > (not (bit-vector-p object))) > > (listp object)) > > (when *unquote-occured* > > (error-of-type 'error > > (TEXT "~S: unquotes may occur only in (...) or #(...) forms") > > 'read))) > > what if we had something like > > `(foo #2A((a b) (,c d))) ?? Although *that* particular case will be handled by the fact that #2A reader will bind *reading-array* to T, which is checked by the COMMA-READER, the flaw you are thinking of is demonstrated by: `(foo #S(my-struct :foo ,c)) ;; no read error Boy, is my face red. *blush* I think that there is no nice way to get around the coupling between the backquote reader and the array and struct readers. Regardless of who establishes the special variable, the other has to dynamically clobber it. Either backquote-reader binds *reading-array* to NIL, or the array-reader binds *unquote-level* to zero. Looks like I have a tiny little bit of work to do here. What I will do is generalize the *reading-array* variable to also indicate that a struct is being read (and change its name). The advantage of this approach, rather than fiddling with *backquote-level* is that we can produce a more informative error like ``unquote in wrong type object'' rather than the confusing ``comma outside of backquote'' which appears to contradict the structure of the text that the user actually typed. The aim is to have distinct errors for the situations of naked unquotes, unquotes that outnumber backquotes, and unquotes in wrong objects. |
From: Kaz K. <ka...@as...> - 2003-03-30 03:39:35
|
* Scanning directory structure. * Analyzing 73 added files. * Analyzing 7 removed files. * Determining move candidates. * moving utils/unicode/ftp.unicode.org/UnicodeData.txt -> utils/unicode/UnicodeDataFull.txt (confidence 84%) * moving libcharset/README.win32 -> libcharset/README.woe32 (confidence 93%) * removing doc/impnotes.xml * removing benchmarks/fprint.tst * removing benchmarks/cur.log * removing benchmarks/benchmarks.log * removing benchmarks/base.log |
From: Kaz K. <ka...@as...> - 2003-04-01 18:47:18
|
While working on the new backquote stuff, I ran into some irritations with $Log$ keywords in some files in src and src/po. This useless thing just causes merge conflicts. It might be a good idea to get rid of $Log$ and the messages it has generated. The messages are useless out of the context of the version control system anyway, since you need to pull out the old versions and view diffs to make sense out of them anyway. (I was working off a branch made from the 2.30 sources, tracking the latest CVS in another branch, and merging both branches down to my trunk). What else? Oh yes, question: must src/aclocal.m4 be in version control? I've had phony diffs because this was regenerated on its own and then checked in. I had to edit it out of the patch I submitted. I'm not sure why this was regenerated in my stream; perhaps something to do with the Autoconf upgrade to 2.57. Somehow I ended up with a different version of this file in the stream which tracks the CVS, and my main trunk, which is almost the same as that stream, except for the merged backquote changes. |
From: Sam S. <sd...@gn...> - 2003-04-01 19:42:08
|
> * In message <Pin...@as...> > * On the subject of "[clisp-list] Re: CVS issues." > * Sent on Tue, 1 Apr 2003 10:46:17 -0800 (PST) > * Honorable Kaz Kylheku <ka...@as...> writes: > > While working on the new backquote stuff, I ran into some irritations > with $Log$ keywords in some files in src and src/po. This useless > thing just causes merge conflicts. It might be a good idea to get rid > of $Log$ and the messages it has generated. yes, what files have this? > What else? Oh yes, question: must src/aclocal.m4 be in version > control? I've had phony diffs because this was regenerated on its own > and then checked in. I had to edit it out of the patch I submitted. all files generated by autoconf &c are in the CVS because we cannot ask users to install autoconf (in addition to gcc) to build CLISP. I doubt that these issues are of interest to the users, so I set Reply-To to clisp-devel. -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Don't take life too seriously, you'll never get out of it alive! |
From: Will N. <wi...@mi...> - 2003-04-03 15:09:32
|
On Tuesday 01 April 2003 19:46, Kaz Kylheku wrote: > While working on the new backquote stuff, I ran into some irritations > with $Log$ keywords in some files in src and src/po. This useless thing > just causes merge conflicts. It might be a good idea to get rid of > $Log$ and the messages it has generated. Use cvs checkout -kk to stop expanding these. |