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