CLISP - an ANSI Common Lisp

Email Archive: clisp-list (read-only)

[clisp-list] Re: New patch.

From: Kaz Kylheku <kaz@as...> - 2003-03-27 20:14

On 27 Mar 2003, Sam Steingold wrote:

> > On 27 Mar 2003, Sam Steingold wrote:
> > > > * Honorable Kaz Kylheku <kaz@...> 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. ;)

Thread View

Thread	Author	Date
[clisp-list] Re: New patch.	Sam Steingold <sds@gn...>

[clisp-list] Re: New patch.

From: Kaz Kylheku <kaz@as...> - 2003-03-27 18:24

On 27 Mar 2003, Sam Steingold wrote:

> > * In message <Pine.LNX.4.44.0303270725060.12820-100000@...>
> > * On the subject of "Re: New patch."
> > * Sent on Thu, 27 Mar 2003 07:27:39 -0800 (PST)
> > * Honorable Kaz Kylheku <kaz@...> 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. ;)

[clisp-list] Re: New patch.

From: Sam Steingold <sds@gn...> - 2003-03-27 19:49

> * In message <Pine.LNX.4.44.0303270907370.15296-100000@...>
> * On the subject of "Re: New patch."
> * Sent on Thu, 27 Mar 2003 10:23:48 -0800 (PST)
> * Honorable Kaz Kylheku <kaz@...> writes:
>
> On 27 Mar 2003, Sam Steingold wrote:
> > > * Honorable Kaz Kylheku <kaz@...> 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.

[clisp-list] Re: New patch.

From: Kaz Kylheku <kaz@as...> - 2003-03-27 20:14

On 27 Mar 2003, Sam Steingold wrote:

> > On 27 Mar 2003, Sam Steingold wrote:
> > > > * Honorable Kaz Kylheku <kaz@...> 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. ;)

[clisp-list] Re: New patch.

From: Sam Steingold <sds@gn...> - 2003-03-27 23:42

> * In message <Pine.LNX.4.44.0303271157210.18990-100000@...>
> * On the subject of "Re: New patch."
> * Sent on Thu, 27 Mar 2003 12:13:41 -0800 (PST)
> * Honorable Kaz Kylheku <kaz@...> 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.

[clisp-list] Re: New patch.

From: Kaz Kylheku <kaz@as...> - 2003-03-28 00:48

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.

[clisp-list] Re: Meta-CVS digs up renames between CLISP 2.30 and CVS HEAD.

From: Kaz Kylheku <kaz@as...> - 2003-03-30 03:39

* 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

[clisp-list] Re: CVS issues.

From: Kaz Kylheku <kaz@as...> - 2003-04-01 18:47

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.

Re: [clisp-list] Re: CVS issues.

From: Sam Steingold <sds@gn...> - 2003-04-01 19:42

> * In message <Pine.LNX.4.44.0304011037190.7897-100000@...>
> * On the subject of "[clisp-list] Re: CVS issues."
> * Sent on Tue, 1 Apr 2003 10:46:17 -0800 (PST)
> * Honorable Kaz Kylheku <kaz@...> 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!

Re: [clisp-list] Re: CVS issues.

From: Will Newton <will@mi...> - 2003-04-03 15:09

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.