This page is part of the web mail archives of SRFI 48 from before July 7th, 2015. The new archives for SRFI 48 contain all messages, not just those from before July 7th, 2015.
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 distinguishingbetween 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 complexformatting of numbers, already provided as separate re-usable proceduresin 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 numericformatting 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 pointrepresentation, which would be a genuine improvement over the current CLformat 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.)