[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:
>    (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

    (display ...)
    (write ...)
    (display ...)

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.