Marc,

Thank you for your, as always, thoughtful response.  I also must apologize to
you and this list for my tardy response.  I was not subscribed to the srfi-48
discussion list and did not receive any missives.  Mea culpa!

Fortunately, I did check the discussion archive.

> Ken, I believe that format strings, as used in the proposed "format"
> procedure as well as C's "printf", is very wrong.

As I see it, the main reasons for a SRFI are to add value and reduce disorder
by specifying common useful functionality across implementations to port code
and programmers.

In this context, I am attempting to reduce disorder among pre-existing FORMAT
functions by proposing something which I feel would minimize changes while
preserving some implementation history.

> The first objection is that it is difficult to type check statically,
> because it requires the parsing of the format string, which may be
> computed at run time.

I agree that this is a classic problem.  I do not attempt to solve it here.

> Secondly, it is hard to remember the meaning of the one letter
> escapes.  How come "~y" does pretty-printing and not "~p", how come
> "~%" prints a newline instead of "~n", etc, etc.

Alas, this is not a new design, but an attempt to codify a common practice.

Scheme48, T, MIT Scheme, Chez Scheme, SLIB, et cetera all implement some form
of a FORMAT (sometimes called SPRINTF) function, much of this over 20 years
ago.

I am not attempting to specify the best mnemonics here -- just common
historical ones.

> Thirdly, the logical link between a particular escape in the format
> string and the parameter it formats is not reinforced.  They are too
> far appart in the source and it is easy to get the order wrong or
> miss one parameter.

What is reinforced is the commonality between the format-string and the
output.  I might point out that using large numbers of arguments to a format
function should be considered bad style.

> Finally it is not composable.  Scheme is a nice functional language
> where we can define functions for each operation we need to do, and we
> can easily compose one function with another to get new
> functionnality.  With format strings these operations are hidden
> behind escape codes that need the "format" interpreter to work.  Why
> not expose those operations as true Scheme functions (that produce
> strings or produce text on the current output port).

The functions, display, write, number->string, and pretty-print are already
exposed.  In a more complete implementation, e.g. SLIB, there are field
specifications for which the commonality of a "format interpreter" make
sense.

I can see how formatted strings can be composed, but not side effects to ports
(monads meet call/cc?).

>...
> Anyway, I don't want to get lost in details.  My main point is that a
> functional interface is much more elegant and versatile that format
> strings.

I do not disagree with you.

Again, the attempt here is to reduce dissonance while retaining continuity
with past practice.  There is no attempt to increase elegance.

Cheers,
-KenD