Forum: Editorial
References: FORMAT, CLHS 22.3.2.1
Category: CLARIFICATION/CHANGE
Edit history: 2004-07-20, Version 1 by Bruno Haible
Status: For CLiki consideration
- Problem Description:
- The interaction between padchar and commachar in FORMAT (CLHS 22.3.2.1) is unclear.
- Proposal (FORMAT-RADIX-COMMACHAR:???):
- Test case:
- Rationale:
- Current practice:
- Cost to Implementors:
- Cost to Users:
- Cost of Non-Adoption:
- Benefits:
- Aesthetics:
- Discussion:
- Bruno Haible says: The explanations of mincol, padchar, commachar, comma-interval need to be copied from 22.3.2.2 to 22.3.2.1. The only thing that is not clear about 22.3.2.1 is what happens if some prefix parameters are given but the radix is not given (e.g. "~,5R"). Also, the (format nil "~19,0,' ,4:B" 3333) example is wrong (argument 0 is not a character). Other than that, everything is clear.
-
Harald Hanche-Olsen says: Not everything is clear to him. The ~D writeup in 22.3.2.2 says "When the : modifier is given to any of these directives, the commachar is printed between groups of comma-interval digits." This becomes clear if, and only if, it is clear whether or not the padchar is considered a digit. Maybe it should depend on whether it is, in actual fact, a digit (according to the given radix)? For example,
(format nil "~10,'*:D" 12345) => "****12,345" but
(format nil "~10,'0:D" 12345) => "00,012,345".
(Anyone who uses a digit other than 0 as the padchar deserves what he gets, of course.) Oh, but I see one problem with this: If you print a negative number, if you were to follow this thinking to its inevitable conclusion, the minus sign would need to be moved in front of all the padding zeros. Maybe the right answer, after all, is to never consider the padchar as a digit, even if it happens to be one.
Added later in the day: It has been brought to my attention that this has been discussed several times on comp.lang.lisp. See the thread on comp.lang.lisp in 2001. - James A. Crippen says: I think it's pretty certain that most users expect the padchar 0 to be treated as a digit, and hence be filled with commachars, even though it is specified as padding. This is conventional with representations of binary values, as in the broken Hyperspec example mentioned by Bruno Haible. In this case I think the spec should be amended to cover the special case of 0 as a padchar which requires commachars to be inserted appropriately. No other character however should receive this special consideration. This amendment would be in keeping with the Principle of Least Astonishment.
- Bruno Haible says: If the integer 0 would be allowed as pad-char, requiring commachar to apply to the leading zeroes, then the minus sign should be handled the same way: it should be positioned before the leading zeroes, not after. This would solve the issue that Aubrey Jaffer has with FORMAT (see here): (format nil "~8,'0,X~%" -3) returns "000000-3", whereas he wants "-0000003".
- Harald Hanche-Olsen agrees with James A. Crippen and Bruno Haible (for what it's worh).
- Discussion: