[plt-scheme] Specifying number precision to display

From: Joseph Osako (scholr1 at comcast.net)
Date: Mon Aug 23 19:04:26 EDT 2004

At 21:57 2004-08-22 -0400, Neil W. Van Dyke wrote:
>Awhile ago, in response to a cookbook question, I wrote most of a small
>number-formatting library, but wanted to rethink the API, so I never
>polished up the code for release.  Should I add this back on my TODO
>list?

Good question. On the one hand, there already exists at least one version 
of the SRFI-28 (format) function (similar to the Common Lisp function of 
the same name), so at least *some* form of numerical string formatting *is* 
already available. There's also the SRFI-54 (cat) function, but apparently 
Dr Scheme 2.08 doesn't support it; I'm presently trying to get the 
reference implementation to work, but it requires SRFI 51, which isn't 
supported, either, so I guess I'll try to bring that one up first, if I 
can. It also seems that the RefImp doesn't indent correctly in Dr Scheme, 
but that's probably due some mistake on my part.

OTOH, the use of general-purpose formatting is a standing (if minor) holy 
war; many consider tools which parse formatting strings to be inefficient, 
and/or that formatting strings, which essentially amount to their own 
language, require more effort to code and maintain than using multiple 
function calls for separate parts of a formatted output. SRFI-64 seems to 
take this last argument into account, as (cat) avoids the use of a 
formatting string in favor of a complex but relatively consistent varadic 
argument list. Still, one could argue that this is still too complex a 
function, and might prefer one that is specifically for formatting numbers 
(or even separate ones for different type of numbers).

What is widely agreed upon is that regardless of it's actual operation, it 
is better for a formatting function to return a string rather than printing 
to the console directly, or at least provide an option to do so; in C 
terms, this is comparable to using sprintf() to produce a string, then 
printing it with puts(). The (format) function, for example, returns a 
string; (cat) does as well, but can take an optional argument to either 
display or write to a given port directly. This separation of operations 
not only simplifies the I/O functions, and moves formatting into the 
category of string manipulation where it (arguably) belongs, but also 
allows the client-programmer to use the formatting for purposes other than 
I/O, and/or perform their own manipulations on the string before printing it.  

Posted on the users mailing list.