[R6RS] Timeline for R6RS SRFIs

[Michael Sperber]

"Manuel Serrano" <Manuel.Serrano at sophia.inria.fr> writes:

> Mike writes,
>
>> That doesn't scale, and is much harder than you seem to think.
> I don't know what I seem to think. I only know that Bigloo supports procedural
> ports and I only know that it's convenient because it allows users
> to define new kind of ports. For instance, two Bigloo libraries
> uses procedural ports for defining SSL ports and GZIPed ports. 

I assume you mean OPEN-INPUT-PROCEDURE, as documented in the Bigloo
manual:

> Returns an input-port able to deliver characters from procedure. Each
> time a character has to be read, the procedure is called. This
> procedure may returns a character, a string of characters, or the
> boolean #f. This last value stands for the end of file.

First off, it is unclear how this relates binary and textual data.
(But this could be rectified easily.)  Moreover, it's unclear how
closing a port works, other than through some implicit mechanism such
as finalization.  This also has performance problems because it
doesn't support block I/O.  Also, it doesn't support random access
(which the Bigloo I/O layer generally supports, if I read the
documentation correctly).

In summary, it means you can't define the built-in port types through
this interface, certainly not efficiently.

Also, there doesn't seem to be any OPEN-OUTPUT-PROCEDURE---but
defining one in the same way as OPEN-INPUT-PROCEDURE probably wouldn't
be hard.

Note that I'm not at all averse to what you call "procedural
ports"---readers and writers as per the Primitive I/O layer SRFI 68
are simply records of the primitive operations of an I/O object, and
SRFI 68 allows you to create streams and ports from them.  The issues
the Primitive I/O layer addresses are exactly the ones mentioned above
that are missing from OPEN-INPUT-PROCEDURE.

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla