[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Format strings are wrong
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
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
I am not attempting to specify the best mnemonics here -- just common
> 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
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
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.