[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a preface
* 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
Through FMT procedure.
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
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
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.
(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 <input-port> 'concat)
But if read-line is defined in FMT's way, it can be used like this;
(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
>> | 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
>> | 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?
I would like to use FMT like this:
(fmt 123 (fmt 1234 '(1 1) ...) "string" (fmt ...) ...)
(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.