Issue: FORMAT-COMMA-INTERVAL

[Pavel.pa@Xerox.COM]

Issue: FORMAT-COMMA-INTERVAL
References:  FORMAT integer printing (p. 388-9)
Category:   ADDITION
Edit history: Version 1, Pavel, June 10, 1987

Problem description:  There are times when users would like to print out
numbers with some punctuation between groups of digits.  The "commachar"
argument to the ~D, ~B, ~O, ~X, and ~R FORMAT directives was introduced
to fill that need.  Unfortunately, the interval at which the commachar
should be printed is always every three digits.  This constraint is
annoying when a different interval would be more appropriate.

Proposal (FORMAT-COMMA-INTERVAL:YES): Add a fourth argument to the ~D,
~B, ~X, and ~O FORMAT directives, and a fifth argument to the ~R
directive, to be called the "comma-interval".  This value must be an
integer and defaults to 3.  When the : modifier is given to any of these
directives, the "commachar" is printed between groups of
"comma-interval" digits.

Test Cases: Under the proposal, the following forms return the indicated
values:
	(format nil "~,,' ,4:B" 13) => "1101"
	(format nil "~,,' ,4:B" 17) => "1 0001"
	(format nil "~19,0,' ,4:B" 3333) => "0000 1101 0000 0101"
	(format nil "~3,,,' ,2:R" 17) => "1 22"
	(format nil "~,,'|,2:D" #xFFFF) => "6|55|35"

Rationale: The current specification of FORMAT gives the user control
over almost all of the facets of printing integers.  Only the wired-in
constant for the comma-interval remains, even though there are uses for
varying that number.  For example, in many contexts, it would be
convenient to be able to print out numbers in binary with a space
between each group of four bits.  FORMAT does not currently allow
specification of the commachar printing interval so users needing this
functionality must write it themselves, duplicating much of the logic in
every implementation's integer printing code.  Other uses, requiring
other intervals, can be imagined.  For example, using a "commachar" of
#\Newline and a "comma-interval" of, say, 72, very large bignums could
be printed in such a way as to ensure line-breaks at appropriate places.

Current practice: No released implementations currently support this
feature.

Adoption Cost: The change in the implementation of FORMAT is reasonably
minor and,  in most cases, highly localized.  Usually, the change is as
simple as taking an extra parameter and using it instead of a wired-in
value of 3.

Cost of non-adoption: Users desiring this functionality will have to
write it themselves, duplicating much of the logic involved in printing
integers at all.

Benefits: The last inflexibility in integer printing is eliminated with
a net increase in user-visible functionality.

Conversion Cost: Since the proposal involves the addition of an argument
to certain directives, the change would be entirely upward-compatible.
No user code would need to be converted.

Esthetics: By parameterizing the final piece of wired-in behavior from
integer printing, this small part of the workings of FORMAT would be
perceived as having been cleaned up.

Discussion: Pavel supports this proposal.