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 ,@. 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) ...) -> `(... ,@a b c ...) [1]

while your requirement is

     ``(... ,@,@(list a b c) ...) -> `(... ,@a ,@b ,@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