[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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? ]
> 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))
>>> (print "list: " (field '(one "two" 3)))
>>> Likewise, we can make a procedure:
>>> (define (cat . objects)
>>> (let ((string-port (open-output-string)))
>>> (for-each (lambda (object)
>>> (display object string-port))
>>> (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
>>> | yield string-ports, rather than strings; which could then even be made
>>> | general if formatting functions themselves were able to accept
>>> | 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>
>>> Additionally, even though FMT is not fully extensible, If <output-port>
>>> parameter is added to FMT, it can print the resulting string like FORMAT,
>>> If <input-port> parameter is added, `file->string' function can be added,
>>> If <separator> parameter is added like '(#\, 3), comma separator function
>>> be added.
>>> | - lastly, although personally I too would like format specifications to be
>>> | as succinct as possible, I suspect that all format specifications
>>> | more than a single specifier should be tagged with at least a single
>>> | 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-