[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.



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