[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a preface
* From: David Van Horn <dvanhorn@xxxxxxxxxx>
* Date: Wed, 24 Mar 2004 02:38:01 -0500
* Subj: 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.
I don't think so.
>> (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.
I have never seen any example of spec of this sort of parameters.
Let me know the way to describe this spec.
| 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?
I think they are FMT's forte.