>From: Paul Schlie <xxxxxx@comcast.net> Subject: Re: Another alternative (Re: format strings are the Right Thing) Date: Mon, 29 Dec 2003 20:01:06 -0500 > However my gut feel is that format procedures/macros should likely yield > an <input-ports>, as opposed to directly writing to an <output-port>; > as it would seem that being able to produce and accept <input-port> > pipes as arguments would enable the ability to compose relatively > sophisticated efficient format/text-processing hierarchies quite easily, > without requiring the use of potentially inefficient and/or cumbersome > intermediate strings to buffer text between transform layers. I generally agree that it would be more flexible and potentially more efficient that the formatter returns a generator, but I wonder if an input port is a good abstraction. I'd rather like to have fmt-* return a lazy stream with semantics defined specifically for this purpose, instead of a generic input port. Since I see a port is more than a lazy stream. A port abstracts I/O as a character generator/consumer in R5RS; although it is a nice abstraction, it is hardly enough to suffice I/O operations required by practical applications. Distinction of binary and character I/O is one example. (I won't go "what is a character" discussion here, but just assume there is a difference). Furthermore, multithreading srfis (srfi-18 and srfi-21) require that ports need to synchronize reads and writes. Even the programmer knows the port fmt-* returns won't be passed to other threads, fmt-* procedure itself doesn't know about that and must return a thread-safe port (unless with some kind of whole program analysis). If we assume fmt-* return an opaque lazy input stream which can only be passed to other fmt-* procedures or pipe, then we can encapsulate those dirty bits inside the implementation of those procedures. (For example, what if one of the formatters feeds a binary chunk? Currently, only the implementator knows how it should be read out from the stream and passed to final destination port). --shiro