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