[Ecls-list] Problems with #= and #./#+/#-/user macro

David Brown lisp at davidb.org
Tue Jan 4 03:49:39 UTC 2011


On Mon, Jan 03 2011, Juan Jose Garcia-Ripoll wrote:

> The specification of #= seems to be ill defined with respect to its interaction
> with reader macros. Take this:
>
>  #1=(1 2 3 #.(print '#1#))
>
> it crashes SBCL and produces garbage in ECL. Similar problems about the

It doesn't seem to crash if *print-circle* it set to 't'.  It seems to
print various internal symbols, though.  SBCL prints an uninterned
symbol.  Clisp prints a #<READ-LABEL 1>.  CCL prints what appears to be
an intermediate construction of the list.

All seem to return the correct list, however.  But, the value printed
seems to be not-well-defined.

> interaction between #+ and #=
>
> (1 2 #+#1=(:ecl) 3 #+#1# 4)

I can make this work in all non-ECL lisps, by doing something like:

  (1 2 #+#1=:ecl 3 #+#1# 4)

or

  (1 2 #+#1=(or :ecl) 3 #+#1# 4)

But that is a problem with the (:ecl) being an illegal #+ expression.

> or the interaction with #.
>
> (1 #1=2 #.(print #1#))

This also seems to work fine on non-ECL lisp.

> Is the reader for #+,#. expected to do some sharp-eq replacement in the
> resulting forms? What about user code implementing reader macros? How shound
> ECL recognize that an eager replacement is needed when reading inside some user
> reader macro, specially if he/she uses :recursive t???

I don't find anything in the spec that says how these should behave.
The closest is that #+ should read the feature expression, and then read
the following expression.  But, I'm not sure the object is required to
be well defined until the entire top-level form is defined.

Hopefully others have more insight.

David




More information about the ecl-devel mailing list