Re: Format strings are wrong Alex Shinn 29 Dec 2003 02:34 UTC
At Sun, 28 Dec 2003 16:24:01 -0500, Taylor Campbell wrote: > > 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. Personally I think there are a lot of things that should be done different from CL FORMAT, including the already discussed ~P and ~C. That doesn't make FORMAT a bad thing either. > 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: > > (reset > (format FORMATTER > (lambda (char) (shift k (stream-cons char (k))))) > stream-null) You can do this with CL format too. Or just FORMATTER. To avoid confusion in the discussion, can you use a different name than format? fmt works, as does funcall (since that's what it is). > If we cared that much about conciseness, we'd all be using Perl or > GOO. But we don't care _that_ much. It has it's place though, and if in a quick script I can save typing four lines by writing a single short format I will. In a larger application I'm more likely to want to use a (localized) format rule which I will grab from a config file. As such, I generally consider (begin (display ...) (write ...) (display ...) (newline)) to be bad style in both cases. > > 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. You can only choose from pre-defined formatter procedures, that's a whole world of difference. > 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. Because eval is evil. Because restricted languages are easier to verify and easier to optimize. > Formatter procedures can easily be arbitrarily nested however you like. As can format strings, as can format lists. > 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?). So use longer names. There's no reason format has to use ~X instead of ~NAME~. Or some combination of both styles. -- Alex