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.
Sorry, last formatted list object should not have been quoted: => "(10 3 +) #e+12.000 a str (3 #\\s \"string\")" > From: Paul Schlie <schlie@xxxxxxxxxxx> > Date: Tue, 30 Mar 2004 09:32:21 -0500 > To: <srfi-54@xxxxxxxxxxxxxxxxx> > Subject: Re: feedback > Resent-From: srfi-54@xxxxxxxxxxxxxxxxx > 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 <tilde@xxxxxxxxxxx> >> ... >> 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 >> >