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