[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