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) 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)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It may be bad manners to talk with your mouth full, but it isn't too good either if you speak when your head is empty.
On 2/20/14, 7:32, Faré wrote:
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) 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)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It may be bad manners to talk with your mouth full, but it isn't too good either if you speak when your head is empty.
Recorded as [ticket-349][]. Thanks for the morning subtlety…
[ticket-349]: http://abcl.org/trac/ticket/349
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) 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.
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)
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.
On Thu, Feb 20, 2014 at 2:50 AM, Pascal J. Bourguignon pjb@informatimago.com wrote:
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 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.
Faré fahree@gmail.com writes:
On Thu, Feb 20, 2014 at 2:50 AM, Pascal J. Bourguignon pjb@informatimago.com wrote:
[…] 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.
I would rather have a CDR written to specify this case ;-)
On Feb 20, 2014, at 19:44 , Pascal J. Bourguignon pjb@informatimago.com wrote:
Faré fahree@gmail.com writes:
On Thu, Feb 20, 2014 at 2:50 AM, Pascal J. Bourguignon pjb@informatimago.com wrote:
[…] 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.
I would rather have a CDR written to specify this case ;-)
CDRs are good :)
Cheers — Marco
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.
armedbear-devel@common-lisp.net
-
Faré -
Marco Antoniotti -
Mark Evenson -
Pascal J. Bourguignon