[plt-scheme] Specifying number precision to display
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.