[plt-scheme] Specifying number precision to display

I gottat put in my 2 cents worth here.  In 30-odd years of programming I've
never had any other feeling for output programming than utter loathing.  As
a result, I've always been a fan of formatting functions/commands/... that
allowed me to do the repetitive stuff relatively simply.  My personal
favorite is Common Lisp's format, in spite of Aubry Jaffer's objections to
its number formatting.  With it I can do fairly sophisticated text output
formatting without much work beyond expressing what I want in the
(admittedly arcane) spec language.  I find the idea that I have to write my
own library of left pad, right pad, item-length-relative functions
ludicrous, since someone's already built that library -- format.  If you
need the layout sensitivity that Jaffer talks about, use his functions; for
much of the rest, give me format.

I find the programmability particularly nice, since I can write lisp code
that computes interesting results and then use format to produce, for
example, LaTeX source -- typeset-quality output that's never touched by
human hands.

There, I feel better now :-)

 -- Bill Wood

----- Original Message ----- 
From: "Joseph Osako" <scholr1 at comcast.net>
To: "Neil W. Van Dyke" <neil at neilvandyke.org>; "Jordan Johnson"
<jorjohns at cs.indiana.edu>
Cc: <plt-scheme at list.cs.brown.edu>
Sent: Monday, August 23, 2004 6:04 PM
Subject: Re: [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.
>