[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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