Faré <fahree@gmail.com> writes:

...

Subtle bug in ABCL.

What should this form read as? `#5(1 ,@`(2 3))

ECL, LispWorks and fare-quasiquote agree on #(1 2 3 2 3) Oops, bad copy/paste. The correct answer is #(1 2 3 3 3) indeed as pjb

On Thu, Feb 20, 2014 at 2:50 AM, Pascal J. Bourguignon <pjb@informatimago.com> wrote: points out, and ECL, LispWorks and fare-quasiquote get it right.

...

allegro, ccl, clisp, sbcl return the arguably conformant #(1 2 3 2 3 2 3 2 3) abcl, cmucl, gcl, xcl all return the arguably completely buggy #(1 2 3)

#5( anything ) should return a vector of dimension 5 in any case.

That's also my interpretation. allegro, ccl, clisp, sbcl, seem to disagree.

Furthermore,

"If the number of objects supplied before the closing ) is less than the unsigned decimal integer but greater than zero, the last object is used to fill all remaining elements of the vector."

so they're all wrong, and expected result should be: #5(1 2 3 3 3)

No, I was wrong in copy/pasting. The result is indeed #(1 2 3 3 3). Mea culpa.

Basically,

`#5(1 ,@`(2 3))

should take:

`#(1 ,@`(2 3))

which all implementation agree that's read as:

#(1 2 3)

and extends the last element to give:

#5(1 2 3 3 3)

Now, since the reader macro is #\`, we should really apply #\` rules, but the only rule for vectors is:

* `#(x1 x2 x3 ... xn) may be interpreted to mean (apply #'vector `(x1 x2 x3 ... xn)).

so one could argue that there's no rule for `#n(…), and therefore it's not a conforming form anyways.

If #n(…) is collapsed to #(…) then the abcl result is correct, as per the above rule.

Maybe it should be an error, then, or demons should be made to fly out of one's nose. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Some cause happiness wherever they go. Others whenever they go.

...

...

so one could argue that there's no rule for `#n(…), and therefore it's not a conforming form anyways.

Maybe it should be an error, then, or demons should be made to fly out of one's nose.

I would rather have a CDR written to specify this case ;-)

Well, if we were to re-open standardization of backquote to handle more cases, I would argue for defining an extensible protocol for the reader, quasiquotation, and pretty-printer, which would allow backquote and commas to work in arbitrary data structures, rather than merely lists and arrays: by associating with each reader macro a constructor (vector for #(), some make-foo for #S(foo ...), etc.), said constructor can be called either at read-time, macro-expansion time, runtime, etc., depending on the quasiquotation status, and then unquote can be made to work fine. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Always strive to be the best yourself you can be. For you can't possibly be anyone else, anyway.