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
>