[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)
Am I missing something? This looks like a convoluted way of writing
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
and SRFI 28, and likely what this SRFI will end up defining if its
therefore spirit remain unchanged].
I also don't see much point in putting a lot of effort in
between formatting to strings and formatting to ports,
I don't see what you're talking about here. What distinction have I
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
formatting to output ports. There is no portable way in Scheme to
output port. (But what is left to be desired by R5RS's I/O system is
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
in all of the CL-style format implementations.
Yes, I certainly agree that a good numeric formatting library is a good
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
with this SRFI and SRFI 28: there's no way to define one's own
directives, whereas with LAMBDA: The Ultimate Formatter, it's quite
if SRFI 48 defined good numeric formatting routines, there would
times when one should wish to write a formatting directive for one's
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
format design. A monadic implementation may work well for this.
Yes, I considered this earlier today, but not when I initially wrote
at three in the morning. (The current radix, default precision, et
would be better done with a fluid variable system, e.g. SRFI 39,