Email list hosting service & mailing list manager

format strings are the Right Thing Alex Shinn (29 Dec 2003 03:08 UTC)
Re: format strings are the Right Thing Tom Lord (29 Dec 2003 06:29 UTC)
Re: format strings are the Right Thing Paul Schlie (29 Dec 2003 19:52 UTC)
Re: Another alternative Shiro Kawai (30 Dec 2003 04:01 UTC)
Re: Another alternative Paul Schlie (30 Dec 2003 05:08 UTC)

Re: Another alternative Shiro Kawai 30 Dec 2003 04:01 UTC

>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