A clisp format procedure among others, seems quite reasonable,

<input-port> (fmt-clisp <string> <arg> ...) ; to each his own.

However my gut feel is that format procedures/macros should likely yield
an <input-ports>, as opposed to directly writing to an <output-port>;
as it would seem that being able to produce and accept <input-port>
pipes as arguments would enable the ability to compose relatively
sophisticated efficient format/text-processing hierarchies quite easily,
without requiring the use of potentially inefficient and/or cumbersome
intermediate strings to buffer text between transform layers.

-paul-

> From: Shiro Kawai <xxxxxx@lava.net>
> 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.
>
> Can't we do the similar thing here?
> I haven't thought it out well, but the basic idea is like this:
>
> [macro] sfmt <SFMT-SPEC> ...
> Generates a "formatter" closure.  Which takes output port and list of
> args, and emit the formatted output to the given port.
>
> SFMT-SPEC ::
> <string>                ; literal string to be displayed.
> (write [limit N])       ; take next arg and write it (up to N chars)
> (display [limit N])     ; take next arg and display it (up to N chars)
> (integer [width N][pad C]) ; format as integer
> (float [width N][precision P] ...) ; format as flonum
>  ;; and so on ...
> (cl-formattr <string>)  ; traditinal CL-style format string
>
> And the ability to insert evaluated expression in SFMT-SPEC will allow
> the programmer to insert other formatter closure into SFMT-SPEC template.
> (But I have an uneasy feeling about the "implicit backquote" feature
> of SRE... it looks like it make difficult to write a macro that
> generates SRE, though  I haven't used SRE extensively so I can't tell
> for sure).
>
> The legacy format can be defined easily, to support the legacy code:
>
> [procedure] format output-port string . args
> == ((sfmt (cl-formatter string)) output-port args)
>
> [procedure] format string . args
> == (let ((out (open-output-string)))
>     ((sfmt (cl-formatter string)) out args)
>     (get-output-string out))
>
> We could also expose low-level build-in formatter procedure,
> which could be similar to the one Paul showed.
>
> Issues:
> - What should formatter closure return? - you might want to
>  switch behavior by whether the output is chopped by the length
>  limitation or not, for example.   Also the you need to know
>  how many args are consumed by other formatter procedure embedded
>  in SFMT-SPEC.
> - How to handle reordering of the arguments?  Reordering makes
>  composition of formatters difficult, but is there a better
>  way to support internationalization of formatting templates?
>  (maybe a named argument instead of positional argument?)
>
> --shiro
>