This page is part of the web mail archives of SRFI 54 from before July 7th, 2015. The new archives for SRFI 54 contain all messages, not just those from before July 7th, 2015.
soo wrote: > Title > > Formatting Although succinct, this is completely nondescript, as is the identifier fmt. > Abstract > > This SRFI introduces the FMT procedure that converts any object to a string. > Unlike the procedure called FORMAT, this FMT procedure takes one object as the > first argument and accepts several optional arguments. This abstract doesn't outline the need for, and design of, the proposal as required by the SRFI Process Document. > Rationale > > The FMT procedure provides a handy optional and functional interface. This rationale is less than detailed. > Specification > > (FMT <number> [[<width>] [<depth>] [<char>] [<radix>] [<plus>] [<exactness>] > [<space>] [<string>] ...]) > (FMT <others> [[<width>] [<count>] [<char>] [<show>] [<case>] [<space>] > [<string>] ...]) The SRFI document must contain a detailed specification. This should be detailed enough that a conforming implementation could be completely created from this description. I don't think that is true of the current specification. Regardless, allowing arbitrary order and arbitrary omission of arguments seems an especially fragile way to specify a procedure. This is why you have to stipulate things like: "<depth> or <count> can be defined only after <width> is defined." If we add more parameters to fmt this problem will blow up, quick. Why does fmt have two very distinct behaviors? Why not have two distinct procedures? Why have a <show> parameter when you can just apply that function to fmt's result? And further, why are you allowed to pass in only display or write? Why have <string> parameters when you have string-append? David