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