On Dec 28, 2003, at 9:06 PM, Alex Shinn wrote:

> At Sun, 28 Dec 2003 02:17:10 -0500, Taylor Campbell wrote:
>>
>> (define (format formatter write-char)
>>    (formatter write-char))
>
> Am I missing something?  This looks like a convoluted way of writing
>
>   (begin
>     (format-proc-1 obj1)
>     (format-proc-2 obj2)
>     (newline)
>     ...)

The point was that that is quite enough, and LAMBDA is a perfect way to
abstract over it.  LAMBDA provides you with extensibility, abstraction,
nestability, and full Scheme, unlike format strings [as defined in this
SRFI,
and SRFI 28, and likely what this SRFI will end up defining if its
title and
therefore spirit remain unchanged].

> I also don't see much point in putting a lot of effort in
> distinguishing
> between formatting to strings and formatting to ports,

I don't see what you're talking about here.  What distinction have I
been
making between formatting to strings and formatting to ports?

>                                                        since we have
> string ports.  Write everything to output to a port.

The problem is that we don't necessarily want just formatting to
strings or
formatting to output ports.  There is no portable way in Scheme to
customize an
output port.  (But what is left to be desired by R5RS's I/O system is
far out
of the scope of this SRFI and is best left to another discussion.)

>                                                       What we are then
> missing are specifically the things you left out, such as more complex
> formatting of numbers, already provided as separate re-usable
> procedures
> in all of the CL-style format implementations.

Yes, I certainly agree that a good numeric formatting library is a good
thing.
But it wasn't the point of my example.  You could easily write numeric
formatting atop LAMBDA: The Ultimate Formatter.  (And this brings out a
problem
with this SRFI and SRFI 28: there's no way to define one's own
formatting
directives, whereas with LAMBDA: The Ultimate Formatter, it's quite
easy.  Even
if SRFI 48 defined good numeric formatting routines, there would
undoubtedly be
times when one should wish to write a formatting directive for one's
own data
structure, or for a different format of an existing one.)

> From a functional perspective you want to pass around info for things
> like counting columns and possibly current "formatting rules" such as
> default radix for numbers and default precision for floating point
> representation, which would be a genuine improvement over the current
> CL
> format design.  A monadic implementation may work well for this.

Yes, I considered this earlier today, but not when I initially wrote
the code
at three in the morning.  (The current radix, default precision, et
cetera
would be better done with a fluid variable system, e.g. SRFI 39,
though.)