* From: Paul Schlie <xxxxxx@comcast.net>
 * Date: Sun, 28 Mar 2004 13:03:46 -0500
 * Subj: Re: feedback

 | Hi Soo,
 | If you have the chance, it may be helpful to read through ALL of the
 | discussions related to the earlier SRFI-48 "Re: Format strings are wrong"
 | postings, as they may be helpful. (as previously noted, it may still be a
 | good idea to first define your broader objectives more formally to help
 | delineate your goals and philosophy in order to help focus the discussions
 | productively; please do not interpret these comments as being antagonistic,
 | as I honestly believe we'd like both like to see the same/similar thing
 | enabled).

Thank you for your advice.

 | Few observations:

 | - personally, believe that some lowest (simplest) level of object->string
 | formatting should be defined to enable the basic strings to be composed from
 | lists of arbitrary scheme objects, which default to utilizing their most
 | likely string equivalent representations, likely those expected by (read).

If we use FMT as (what is called) a formatter, I think it is natural.

   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