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.
Last few observations, in hope they may be helpful: - the \ escapes in the resulting formatted strings I presume are not literally present, but merely print that way; as (string #\a #\" #\b) => "a\"b" although 3 characters long. - The fmt-string (or whatever name, as not differentiating between string, number, etc format routines seems to lead to ambiguities, as noted by others; as (fmt 12 10 3 '+) => "12 10 3 +" would seem perfectly legitimate); who's behavior suggested below is similar to your cat procedure example (unless I'm missing something), except it would basically (eval) and (write) all objects with the exception of string and character arguments, which will use (display) if not quoted; implying it's necessity to be implemented as a macro/syntax-def, as otherwise it wouldn't be possible to differentiate between quoted and unquoted string and character arguments; which basically eliminates the necessity to explicitly identify write format attributes, enabling write and display formatted objects to be intermixed relatively easily and reasonably intuitively. -paul- > From: Paul Schlie <schlie@xxxxxxxxxxx> > Date: Tue, 30 Mar 2004 10:24:11 -0500 > To: <srfi-54@xxxxxxxxxxxxxxxxx> > Subject: Re: feedback > Resent-From: srfi-54@xxxxxxxxxxxxxxxxx > Resent-Date: Tue, 30 Mar 2004 17:24:23 +0200 (DFT) > > 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 <schlie@xxxxxxxxxxx> >> Date: Tue, 30 Mar 2004 09:59:07 -0500 >> To: <srfi-54@xxxxxxxxxxxxxxxxx> >> Subject: Re: feedback >> Resent-From: srfi-54@xxxxxxxxxxxxxxxxx >> 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 <schlie@xxxxxxxxxxx> >>> Date: Tue, 30 Mar 2004 09:38:06 -0500 >>> To: Paul Schlie <schlie@xxxxxxxxxxx>, <srfi-54@xxxxxxxxxxxxxxxxx> >>> 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 <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 >>>>> >>>> >>> >> >