soo wrote:
>  * 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.

Great, we're getting nowhere fast.

Seriously, the word "formatting" conveys no information to me.  What are you
formatting?  How?  Why?  -- Answers to these questions should appear somewhere
in the SRFI document.

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

Rather than assuming there is a problem with the specification, have you
considered this is perhaps a poor way of designing parameters to a function?
I would rather see a keyword syntax, or pass in a record to fmt, or fix the
order of arguments.  The current approach 1) has no precedent as far as I'm
aware 2) is not extensible 3) makes it very difficult to read the uses of this
procedure and predict what the result will be.

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

I don't understand this response.  Could you elaborate on what fmt's "forte"
is specifically or respond directly to my questions.

I agree with Jens that a SRFI for the easy formatting of numbers as strings is
a good idea.  However, I would expect such a SRFI to be titled something along
the lines of "Easy Formatting of Numbers as Strings", to include a rationale
detailing why such a SRFI is a good idea, and to include a rationale as to why
the given proposal is a good realization of that idea.

I'm finding it very difficult to provide constructive feedback because I can't
discern from the document what your intentions are at all.  What problem does
this SRFI address?

David