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

Re: Format strings are wrong

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 27, 2003, at 11:37 PM, Alex Shinn wrote:

The SRFI process isn't just about porting, but also standardizing
libraries.  One of the primary motivations of SRFI-1 was that all
Schemes provided varying levels of add-on list utilities with
incompatible API's.

It's also about getting together and producing something _better_ than what J. Random Schemer or Common Lisper thought up a while ago. Remember FLUID-LET? -- there was once a SRFI about it, but it was ditched because there were several arguments about why it was a bad idea, and better ideas. (Actually, I disagree with the design of SRFI 39 (parameters), too, which could be considered to be one of those better ideas, but that's a different story and not really relevant here.) Likewise, if there are good arguments against format strings, and there are good alternative ideas, why should you let yourself be held down by the old and historically motivated idea? I don't claim that LAMBDA: The Ultimate Formatter is necessarily the best idea -- just as I don't think SRFI 39 is the best idea in the related set of ideas regarding fluid variables --, but I think
it's a better idea nevertheless.

  In this case almost all Schemes at least support
SRFI-28, and many support some or all of the full Common-Lisp format,
so it is definitely something people find useful and should be
standardized.  Many people feel SRFI-48 doesn't go far enough, so
there will likely be at least one more format SRFI.  Perhaps that will
explicitly make the individual formatting procedures accessible as
they are in Dirk Lutzebaeck's implementation, which would give you the
option of using both styles.

Of course, and FLUID-LET is easily implemented and available in lots of places. But that does not make it a _good_ thing. Likewise, formatting strings are easily implemented and available in lots of places; indeed, there are portable implementations for full Common Lisp FORMAT. But CL FORMAT isn't necessarily
a good thing.

Possibly something along the lines of simply adopting the notion that:
(str-fmt ....) [or (string ...) be extended] to accept mixed string, symbol, character and numerical arguments, and produces a string resulting from the
concatenation of its argument's string equivalences

Probably best not to overload string, especially in light of recent
discussions as to just what a character is.  Also, the procedure
should definitely output to a port, not a string.  But even using a
port this becomes inefficient if you inline write's:

  (define (write-to-string x) (with-output-to-string (cut write x)))
  (fmt #t "list: " (write-to-string ls) #\newline)

and likewise for performing different number->string conversions in
the middle of a format.

Formatter procedures can work any way you like; all you need is to pass some different WRITE-CHAR procedure, which allows for even more expressiveness. For instance, you could use SHIFT & RESET to generate a stream from FORMATTER:

    (format FORMATTER
      (lambda (char) (shift k (stream-cons char (k)))))

(Assuming the continuations that SHIFT lets you nab are n-ary. It may also be
better to use BSHIFT & BRESET, but that's diverging from this SRFI.)

This doesn't force you to cons up intermediate strings or even intermediate output ports with a specialized character writer. (One might debate about the efficiency of SHIFT & RESET, which I don't want to right now, as it's utterly
beside the point.)

                         You really have to break it apart as:

  (display "list: ")
  (write ls)

which when compared with

  (format #t "list: ~S\n" ls)

looks clumsy and verbose, especially when you have many of these
throughout a program almost tripling the number of lines, and
especially when you have to wrap them in begins.  Format is very

If we cared that much about conciseness, we'd all be using Perl or GOO. But we
don't care _that_ much.

        and not only lets you re-use the format string in parts of
your program, it lets you easily change it at runtime

The same can be said about formatter procedures.

                                                      (even in an
eval-less Scheme) and lets you load it from things like config files.

But what you're really doing there is just creating a very limited language for formatting; it's equivalent to having a very limited EVAL. Why not use EVAL? You could even write an incredibly simple EVAL that supports only LAMBDA,
function application, and the built-in formatters.

Consider the log files of a server that need to produce customizable
output, like this from my httpd.conf:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %T %v" full

Or consider the Emacs mode-line-format string which lets you customize
(again at runtime) what appears in your mode-line.  Of course, Emacs
allows nested lists as the format, which may be a consideration for
future format SRFIs rather than consider introducing artificial
nesting with ~<...~> etc.

Formatter procedures can easily be arbitrarily nested however you like.

By keeping the logic in one place format is also much better suited to
things like i18n, and can provide more efficient control over
columnating and padding.

And you don't need to remember obscure formatting directive syntax with obscure single-character main names and strange syntax to go around it (SRFI 29's ~@*, anyone?). Column & padding control are especially easy when you've got full Scheme at your fingertips with which to write formatting routines. It would be trivial to write a FORMAT/PADDING routine that would keep track of the columns
that the sub-formatters write.

All around, format is more consice [sic], more efficient, and more flexible
than the alternatives.  That doesn't mean we couldn't use some more
functional interfaces, but they will likely not replace format.

Concise [sic], I concede; but do you really want _that_ much conciseness? I'd say no, or, as I said, we'd all be using Perl or GOO. (OK, that's a bit of an
overstatement, but you get the idea.)