Personally I think the intent of the SRFI is reasonably clear, although not
explicitly stated; and attempts to formalize the definition of a flexible
scheme object format (fmt ...) procedure to enable the specification of text
strings which are composed of correspondingly formatted scheme objects in a
more functional style than alternative enable.
However:
- do agree that the srfi's objectives should likely be more clearly stated.
- do believe that it's likely be beneficial to name it's arguments somehow;
but certainly not by using records, as it would destroy it's simplicity.
- but do like the short name fmt as it would need to be short to enable it's
repeated use in the composition of more complex string composition, and
seems more than clear enough for that purpose:
(sting-append (fmt ...) " whatever " (fmt ...) ...)
Making the observations that all numbers are basic variations of:
[[pad][sign][whole][fract/numerator][expt/demominator][pad]]
It may be feasible to corresponding model a format spec around this scheme:
(fmt <obj-inst> <obj-fmt>)
<obj-inst> :: [<exact-num> | <inexact-num> | ...] ; object instance.
<obj-fmt> :: [<exact-fmt>]* ; corresponding object format options.
<exact-fmt> ::
(field <width:0> [<pad:#\space>]) ; specify basic field.
<width> 0 = defalut = chars of width as required by spec.
pos = sized, right justified, left padded to <width> size.
neg = sized, left justified, right padded to <width> size.
<pad> #\space = default = padding character as required.
(spec <sign:#f> <whole:0> <fract/num:0> <expt/den:0> <radix:10> <sep:#f>)
<sign> #f = default, sign not forced, #t = + sign forced if pos.
<whole> 0 = default, digits of precision as required.
pos = <whole> max digits, right justified, no fill.
neg = left filled by most significant digit to <whole> size.
<fract/num> 0 = default, digits of precision as required.
pos = <whole> max digits, right justified, no fill.
neg = left filled by most significant digit to <whole> size.
<expt/den> 0 = default, digits of precision as required.
pos = <whole> max digits, right justified, no fill.
neg = left filled by most significant digit to <whole> size.
<radix> 10 = default, specifies numeric format radix base.
<sep> #f = default, or otherwise separator character between every
n digits, as function of radix, 3 for radix of 10, or 4
Which should allow stuff like:
(fmt 1/3) -> "1/3"
(fmt 1/3 '(field 6)) -> " 1/3"
(fmt 1/3 '(field -6)) -> "1/3 "
(fmt (exact->inexact 1/3)) -> "0.3333333333333333" ; to internal precision.
(fmt (exact->inexact 1/3) '(spec #f 1 3))
-> "1.333"
(fmt (exact->inexact 1/3) '(field 6) '(spec #f 1 3))
-> " 1.333"
(fmt 10.5 '(spec #t 1 8 -4 2 #\,))
-> "+1.0101,000e-0001" ; binary formatted.
Or something like that, possibly with the more named fields to enable more
legible optional specification granularity, and possibly by enabling them to
Be composed in arbitrarily deep lists to enable their being composed as
desired?
(let ((radix '(radix 2)))
(let ((field '(width 12)) (spec '((sign #t) radix))
(fmt something field spec)))
-paul-
> From: David Van Horn <xxxxxx@cs.uvm.edu>
> Date: Wed, 24 Mar 2004 14:36:11 -0500
> To: soo <xxxxxx@tilde.co.kr>
> Cc: srfi-54@srfi.schemers.org
> Subject: Re: a preface
> Resent-From: srfi-54@srfi.schemers.org
> Resent-Date: Wed, 24 Mar 2004 20:38:22 +0100 (NFT)
>
> 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
>
