Hello,
I just fell upon a case where implementations seem to differ on what to do. The question is how to interpret a format directive in which the last parameter is followed by a comma. Consider this test case:
(defun fmt (stream argument colonp atsignp &rest params) (declare (ignore stream argument colonp atsignp)) (format t "~S~%" params))
(format t "~1,2/fmt/~%" t) (format t "~1,2,/fmt/~%" t) (format t "~1,2:/fmt/~%" t) (format t "~1,2,:/fmt/~%" t)
Here's what you get from various implementations:
SBCL / ECL / ABCL: (1 2) (1 2 NIL) (1 2) (1 2)
CMU-CL / CCL / CLISP / Allegro / LispWorks: (1 2) (1 2) (1 2) (1 2)
Funnily, my instinct tells me that nobody's right, as I would have expected to get this:
(1 2) (1 2 NIL) (1 2) (1 2 NIL)
Indeed, the parameters list is implicitely terminated by the directive character OR a colon / at-sign. So using a final comma seems to me like adding another, empty, parameter at the end.
I'm willing to report those divergences to the respective implementations, but the problem is that I don't really know what to report :-) Who's right? No matter how I read the spec, I cannot make a decision and it seems to me that this is an unspecified corner case.
I reckon it's probably not a big deal, but this could be a problem for user-defined functions relying on the actual number of parameters that they get.
Comments?
On Thu, 27 Jan 2011 15:19:47 +0100, Didier Verna said:
Hello,
I just fell upon a case where implementations seem to differ on what to do. The question is how to interpret a format directive in which the last parameter is followed by a comma. Consider this test case:
(defun fmt (stream argument colonp atsignp &rest params) (declare (ignore stream argument colonp atsignp)) (format t "~S~%" params)) (format t "~1,2/fmt/~%" t) (format t "~1,2,/fmt/~%" t) (format t "~1,2:/fmt/~%" t) (format t "~1,2,:/fmt/~%" t)
Here's what you get from various implementations:
SBCL / ECL / ABCL: (1 2) (1 2 NIL) (1 2) (1 2)
CMU-CL / CCL / CLISP / Allegro / LispWorks: (1 2) (1 2) (1 2) (1 2)
Funnily, my instinct tells me that nobody's right, as I would have expected to get this:
(1 2) (1 2 NIL) (1 2) (1 2 NIL)
Indeed, the parameters list is implicitely terminated by the directive character OR a colon / at-sign. So using a final comma seems to me like adding another, empty, parameter at the end.
I'm willing to report those divergences to the respective implementations, but the problem is that I don't really know what to report :-) Who's right? No matter how I read the spec, I cannot make a decision and it seems to me that this is an unspecified corner case.
I reckon it's probably not a big deal, but this could be a problem for user-defined functions relying on the actual number of parameters that they get.
Comments?
It looks underspecified to me.
One argument for not including the trailing nil is that it allows you to pass one nil parameter by using "~,/fmt/".
Also consider the requirement: "If the arg used by a V parameter is nil, the effect is as if the parameter had been omitted." It is uncertain whether the comma is also "omitted" in this case. The GCL ansi test suite checks for this with the ~^ directive, which is sensitive to the number of parameters.
E.g.
(format nil "~{~0,v^~A~}" '(3 8 1 7 3 6 nil 5)) => "876" rather than "8765"
__Martin
Martin Simmons wrote:
One argument for not including the trailing nil is that it allows you to pass one nil parameter by using "~,/fmt/".
That is a very good point!
On Thu, Jan 27, 2011 at 6:19 AM, Didier Verna didier@lrde.epita.fr wrote:
I just fell upon a case where implementations seem to differ on what to do. The question is how to interpret a format directive in which the last parameter is followed by a comma.
I'm willing to report those divergences to the respective implementations, but the problem is that I don't really know what to report :-) Who's right? No matter how I read the spec, I cannot make a decision and it seems to me that this is an unspecified corner case.
One thing you could do is to add a note to this page:
http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
Even if you don't have a strong opinion on what the spec should say, you could note that it is underspecified.
-- Scott
"Scott L. Burson" Scott@sympoiesis.com wrote:
One thing you could do is to add a note to this page:
http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
Even if you don't have a strong opinion on what the spec should say, you could note that it is underspecified.
In fact, I've written a CDR document (not yet submitted) and once it is accepted, I might add an entry in the page you're mentionning. Maybe the contents of this page could be moved to CDR, now that it exists?
In case some of you are interested, I'm attaching a plain text version of my intended CDR submission below (the original is in Texinfo format).