And while I'm at it, how about accepting arbitrary hierarchical lists of
format specifiers such they may be composed without requiring their splicing
into the format specifier list:

(let ((sign-fmt '(-t s: +)))
  (let ((field-fmt '(w: 10 f: 3)))
    (fmt-num 12 sign-fmt field-fmt)))

=> " #e+12.000"

> From: Paul Schlie <xxxxxx@comcast.net>
> Date: Tue, 30 Mar 2004 09:59:07 -0500
> To: <srfi-54@srfi.schemers.org>
> Subject: Re: feedback
> Resent-From: srfi-54@srfi.schemers.org
> Resent-Date: Tue, 30 Mar 2004 16:59:18 +0200 (DFT)
>
> And further sorry, obviously the format keys should themselves have been
> quoted as well to keep things simple, potentially implying that a
> parameter-less specifiers should simply have the form of: 'X ...
>
> (fmt-str a (fmt-num 12 't 's: '+ 'f: 3) " " #\a " str " '(3 #\s "string"))
>
> => "(10 3 +) #e+12.000 a str (3 #\\s \"string\")"
>
> [ apparently, not thinking straight this morning,
> hope I haven't screwed anything else up?       ]
>
> -paul-
>
>> From: Paul Schlie <xxxxxx@comcast.net>
>> Date: Tue, 30 Mar 2004 09:38:06 -0500
>> To: Paul Schlie <xxxxxx@comcast.net>, <srfi-54@srfi.schemers.org>
>> Subject: Re: feedback
>>
>> Sorry, last formatted list object should not have been quoted:
>>
>> => "(10 3 +) #e+12.000 a str (3 #\\s \"string\")"
>>
>>
>>> From: Paul Schlie <xxxxxx@comcast.net>
>>> Date: Tue, 30 Mar 2004 09:32:21 -0500
>>> To: <srfi-54@srfi.schemers.org>
>>> Subject: Re: feedback
>>> Resent-From: srfi-54@srfi.schemers.org
>>> Resent-Date: Tue, 30 Mar 2004 16:32:35 +0200 (DFT)
>>>
>>> Please consider:
>>>
>>> - personally believe fmt-xxx should produce a string (or lazy stream) where
>>> a quoted scheme object, when displayed and then read back, would would be
>>> equivalent, if not quoted, it's simply evaluated and then correspondingly
>>> treated. which I suspect would be more generally useful and intuitive:
>>>
>>> - Per your example below:
>>>
>>> (fmt-str a (fmt-num 12 -t s: '+ f: 3) " " #\a " str " '(3 #\s "string"))
>>>
>>>  => "(10 3 +) #e+12.000 a str '(3 #\\s \"string\")"
>>>
>>> note: where fmt parameters have the form of:
>>>       -X if parameter-less, i.e. -t for display type prefix
>>>       X: if parameterized, i.e. s: <sign> or f: <fraction-digits>
>>>
>>> - the value of fmt-xxx potentially yielding/consuming ports (or streams),
>>> is that it enables lazily evaluated arbitrary length hierarchically
>>> specified format specifications; which would likely be otherwise
>>> potentially physically impractical to achieve.
>>>
>>> (which format does not enable)
>>>
>>> Thanks, -paul-
>>>
>>>> From: soo <xxxxxx@tilde.co.kr>
>>>> ...
>>>>  In SRFI-48 mailing list, Marc Feeley said:
>>>>  ...
>>>>  To make printing easier, a general purpose function called "print"
>>>>  could be added with this definition:
>>>>  (define (print . lst) (for-each display lst))
>>>>  allowing
>>>>  (print "list: " (field '(one "two" 3)))
>>>>  ...
>>>>
>>>> Likewise, we can make a procedure:
>>>> (define (cat . objects)
>>>> (get-output-string
>>>>  (let ((string-port (open-output-string)))
>>>>    (for-each (lambda (object)
>>>> (display object string-port))
>>>>       objects)
>>>>    string-port)))
>>>>
>>>> Examples:
>>>> (cat 12 " " #\a " str " '(3 #\s "string"))
>>>> (fmt 12 " " (fmt #\a) " str " (fmt '(3 #\s "string")))
>>>> => "12 a str (3 s string)"
>>>>
>>>> (define a '(10 3 +))
>>>> (cat a (fmt 12 10 3 '+) " " #\a " str " (fmt '(3 #\s "string") write))
>>>> (cat a (apply fmt 12 a) " " #\a " str " (fmt '(3 #\s "string") write))
>>>> (fmt a (fmt 12 10 3 '+) " " (fmt #\a) " str " (fmt '(3 #\s "string")
>>>> write))
>>>> => "(10 3 +) #e+12.000 a str (3 #\\s \"string\")"
>>>>
>>>> | - as observed in the earlier srfi-48 discussions, it may even be better
>>>> | (both more general, and efficient) to define that resulting format
>>>> functions
>>>> | yield string-ports, rather than strings; which could then even be made
>>>> more
>>>> | general if formatting functions themselves were able to accept
>>>> string-ports,
>>>> | such that more complex hierarchically defined formats may be defined as
>>>> | desired.
>>>>
>>>> FMT manipulates not string ports but strings.
>>>>
>>>> If we have a procedure like `open-output-string?', we can make FMT to
>>>> append
>>>> the strings in the string ports to the resulting string like <string>
>>>> parameter.
>>>>
>>>> Additionally, even though FMT is not fully extensible, If <output-port>
>>>> parameter is added to FMT, it can print the resulting string like FORMAT,
>>>> and
>>>> If <input-port> parameter is added, `file->string' function can be added,
>>>> and
>>>> If <separator> parameter is added like '(#\, 3), comma separator function
>>>> can
>>>> be added.
>>>>
>>>> | - lastly, although personally I too would like format specifications to
>>>> be
>>>> | as succinct as possible, I suspect that all format specifications
>>>> containing
>>>> | more than a single specifier should be tagged with at least a single
>>>> letter
>>>> | semi-descriptive symbol to both give a hint as to what the specified
>>>> | controls, and to enable them to be only defined as required in arbitrary
>>>> | ordered lists as convenient to the author, and/or to enable their more
>>>> | flexible construction.
>>>>
>>>> I'll consider it, if conflicts occur among the format specifications.
>>>> Anyway, I think it leaves some room for consideration.
>>>>
>>>> | With a little luck, the above is hopefully also be consistent with your
>>>> | goals for this srfi as well?
>>>>
>>>> | -paul-
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> INITERM
>>>>
>>>
>>
>