This page is part of the web mail archives of SRFI 54 from before July 7th, 2015. The new archives for SRFI 54 contain all messages, not just those from before July 7th, 2015.
* From: Paul Schlie <schlie@xxxxxxxxxxx> * 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