[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another alternative

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