[Ecls-list] Splice-splice interpretation

[Juan Jose Garcia-Ripoll]

I CC a discussion in the bug tracking system about ,@ and friends. I copy
it here because:

* I do not consider it valid a single person telling me what is the right
interpretation of the standard.

* I am a bit tired of other implementations claiming to be 100% ANSI
compliant and introducing nonconformant things that other people end up
taking as the right thing.

In any case, *I have been convinced in the past* about changing things, but
this change seems dramatic enough (it touches various things in the
reader), that I would rather wait for compelling arguments.

Best,

Juanjo

----

The original posts and thread: http://sourceforge.net/p/ecls/bugs/251/

The grammar for backquote:
http://www.lispworks.com/documentation/HyperSpec/Body/02_df.htm

My last answer:

The behaviour of backquote is defined in terms of what forms they produce
and the reader in ECL applies strictly the specification, by which there is
NO NEED to create any intermediate structure at all: ,@ is recognized
inside a list and produces a an append form, "," does something similar,
etc. The result is that there is no need to spill out
backquote/quote/splice symbols unlike what SBCL does

    [SBCL] * ``(a ,@,@'((list a)))

    `(A ,@(LIST A))

    [ECL] > ``(a ,@,@'((list a)))

    (LIST* 'A (LIST A))

I personally prefer the last approach, as it produces code that is directly
Common Lisp and not some set of forms that still have to be macroexpanded.

It is because of this difference that your expected behavior does not work
at all. When the reader sees ``(... ,@,@(list a b c) ...) it tries to
generate the form associated to ,@ but it lacks completely a context, since
that ,@ does not form part of any list at all.

Let me insist on this:

1) In the ANSI specification backquote syntax is defined with a single
level of  equalities, without any recursive behavior where inner behavior
depends on external conditions.

2) Your expected behavior is that ,@ acts recursively on the elements
produced by some , at . This requires some deeper definition than the one
provided by ANSI.

3) Moreover, this last definition is contradictory with the one in ANSI,
which states that the elements of ,@ are spliced or spilled in place in the
form. If I relax this definition ignoring the fact that the ,@ is not
inside any list I should get

    ``(... ,@,@(list a b c) ...) -> `(... , at a b c ...) [1]

while your requirement is

     ``(... ,@,@(list a b c) ...) -> `(... , at a , at b , at c ...)

Note that [1] could be somebody's own interpretation of what is closer to
the spirit and still not being covered by the current specification.


-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20130123/6ab04865/attachment.html>