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

Re: Another alternative (Re: format strings are the Right Thing)

On Mon, Dec 29, 2003 at 01:55:32PM -1000, Shiro Kawai wrote:

> I got an impression that this format string discussion has similarity
> to the regexp pattern language---it defines a mini-language,
> it has long history tons of variations, it is concise in typical
> usage but can't be composed well and tend to produce an
> incomprehensible code when one try to push it too hard.
> And Olin Shivers showed a solution, SRE.

But SRE is still a mini-language.  Indeed, I've been suggesting
possibilities of using arbitrary lists or more verbose format strings.
I think the primary arguments are against using any kind of
mini-language at all vs. just using normal function composition of
write and display.

My second re-implementation of format is at


which does something similar to what you suggest.  Actually, CL *does*
have a macro to general format closures, but there's no reason we need
to use macros.  The new format has a customizable parser, with
customizable dispatch characters, and multiple inheritance of other
dispatch closures.  This (as I suggested in an earlier mail) lets you
build a tower of format procedures.  It also lets you cache static
formatters, so you can write

  (define my-fmt (srfi-48-format 'static-formatter "s: ~S b: ~B"))

and apply my-fmt to format arguments without re-parsing.

Included examples are implementations of SRFI-28 and SRFI-48, an
implementation of SRFI-19 that is much faster than the current SRFI-19
(and more customizable), and a simple printf implementation (which you
could inherit from and replace the % with a ~).

Currently I'm trying to decide how to best pass state around when you
want, for example, a column formatter, and hopefully how to avoid that
for format strings that don't use it.