[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a preface

This page is part of the web mail archives of SRFI 54 from before July 7th, 2015. The new archives for SRFI 54 contain all messages, not just those from before July 7th, 2015.



 * From: David Van Horn <dvanhorn@xxxxxxxxxx>
 * 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