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.
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 http://synthcode.com/scheme/format2.scm 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. -- Alex