[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Format strings are wrong
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:
> (format FORMATTER
> (lambda (char) (shift k (stream-cons char (k)))))
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
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
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.