* From: David Van Horn <xxxxxx@cs.uvm.edu>
 * Date: Wed, 24 Mar 2004 02:38:01 -0500
 * Subj: Re: a preface

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

I don't think so.

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

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

I think they are FMT's forte.

Soo
--
INITERM