Re: LAMBDA: The Ultimate Formatter (was Re: Format strings are wrong)

[Taylor Campbell <campbell@xxxxxxxxxxxx>]

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.)