[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a preface
Although succinct, this is completely nondescript, as is the identifier fmt.
> 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.
> The FMT procedure provides a handy optional and functional interface.
This rationale is less than detailed.
> (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
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?