Re: Another alternative

[Paul Schlie <schlie@xxxxxxxxxxx>]

The only reason I suggested a port, is that its already considered a unique
data-type which can be discriminated from other arbitrary procedures,
thereby allowing a generalized fmt-xxxx procedure to accept an arbitrary
scheme data type including procedure symbols, and do the right thing.

Ideally it would be nice to be able to define arbitrary new procedural data
types (actually, although many scheme implementations support the ability to
define procedures which yield ports, R5RS doesn't formally require it, so
shy of getting the scheme author team to advocate the addition of such or a
more generalized type definition facility, your suggestion may likely be the
best short term option in general).

-paul-

> From: Shiro Kawai <shiro@xxxxxxxx>
> Date: Mon, 29 Dec 2003 18:01:09 -1000 (HST)
> To: srfi-48@xxxxxxxxxxxxxxxxx
> Subject: Re: Another alternative
> Resent-From: srfi-48@xxxxxxxxxxxxxxxxx
> Resent-Date: Tue, 30 Dec 2003 05:01:32 +0100 (NFT)
> 
> 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
>