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

 | soo wrote:
   >> >> Title
   >> >> Formatting
   >> | Although succinct, this is completely nondescript, as is the identifier fmt.

Why not let-recursive?  Why not exponent?  Why not abstract?
But I don't adhere to this name of the procedure and I can follow Whatever
most people agree to.

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

Not we but I.

 | Seriously, the word "formatting" conveys no information to me.

The word reminds me of a procedure FORMAT.

 |What are you
 | formatting?

Any object.

 |How?

Through FMT procedure.

 |Why?

 The same as FORMAT.

 |-- Answers to these questions should appear somewhere
 | in the SRFI document.

Even though you are in the right, that's none of your business.

The SRFI Process Document says: At the discretion of the editors, a proposal
that does not completely conform may be moved to draft status (although it
must conform before it will be moved to final status).

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

No.  Please let me know the way to describe the spec of this sort of procedure.

 | I would rather see a keyword syntax, or pass in a record to fmt, or fix the
 | order of arguments.

I have no ideas to express the function of FMT in those ways.
Please, Let me show an example.

 |The current approach 1) has no precedent as far as I'm
 | aware

Have you never tried anything new?

 |2) is not extensible

What is not extensible?

|3) makes it very difficult to read the uses of this
 | procedure and predict what the result will be.

I don't think so.  Please check SPEC and EXAMPLES of this SRFI document.

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

I know Scheme procedures can have a variable number of arguments.  If the
function of the arbitrary order can be added, it will be more convenient to
use the procedure.

Example:
(read-line [<port>] [<option>])
 * <port> is an input-port.
 * <option> is a symbol: 'trim 'concat ...
(define (read-line . port-option) ...)

If read-line is defined in conventional way, it is used like this;
(read-line)
(read-line <input-port>)
(read-line <input-port> 'concat)

But if read-line is defined in FMT's way, it can be used like this;
(read-line)
(read-line <input-port>)
(read-line 'concat)
(read-line 'concat <input-port>)
(read-line <input-port> 'concat)

Why not convenient?

If the type or the required value of the arguments is different, FMT's way
follows a free sequence style.  If not, FMT's way follows floating sequence
style (cf. Every conventional way follows fixed sequence style.).
In conclusion, The read-line procedure can be defined in free sequence style
and the FMT procedure is defined in both free sequence and floating sequence
style.

>> | Why does fmt have two very distinct behaviors?

Because the required optional arguments are different according to the type.

>> | Why not have two distinct
   >> | procedures?

Why must have two procedure?  Inspite of the same processing course and return
type(string).

>> | Why have a <show> parameter when you can just apply that function to fmt's
   >> | result?

To write an object to a string port.

>> |And further, why are you allowed to pass in only display or write?

FMT needs only display and write.

>> | Why have <string> parameters when you have string-append?

For convenience.
I would like to use FMT like this:
        (fmt 123 (fmt 1234 '(1 1) ...) "string" (fmt ...) ...)
instead of
        (string-append (fmt 123) (fmt 1234 '(1 1)) ... "string" (fmt ...) ...).
Do this incommode you?

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

A Note in Preface is helpful.

 | David

--
INITERM