[R6RS] Timeline for R6RS SRFIs

[Manuel Serrano]

On Wed, 08 Jun 2005 14:40:17 +0200
Michael Sperber <sperber at informatik.uni-tuebingen.de> wrote:

> > 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:
No, this is not what I have in mind. 

> > 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.

Even if I was not thinking of the Bigloo's procedure ports, I now answer
your questions... 
> 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.  
I think that it *does* support block I/O. It's up to the procedure to
manage a buffer if it's decided useful.

> Also, it doesn't support random access
> (which the Bigloo I/O layer generally supports, if I read the
> documentation correctly).
Bigloo supports random access on files. It does not support random
access on consoles, pipes, sockets, ..., and procedure ports.
So what?

> 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.
We agree on that.

Now let me describe briefly what I had in mind. A port is a data structure
which contains a bunch of fields which are more or less implementation
dependent:
  - an actual file descriptor
  - a name
  - a buffer
  - a buffer size
  - ...

Amongst these fields three are functions:
  - sysread
  - syseof
  - sysclose

Each of these fields is used to implement the eponym system functionality. 
When the port's buffer has to be filled, the sysread function is invoked.
When a port has be to closed, the sysclose function is invoked, etc.
These functions can accept the port as argument or the buffer. It's not
important. 

This model scales up (as I mentioned it enables user applications to
define new port types) and it is efficient. If you think it's not,
let's try to run some benchmarks in order to have a better understanding
of what we are pretending.

-- 
Manuel