[R6RS] Timeline for R6RS SRFIs

[feeley at iro.umontreal.ca]

Quoting Michael Sperber <sperber at informatik.uni-tuebingen.de>:

> 
> Marc Feeley <feeley at iro.umontreal.ca> writes:
> 
> > The following topics are not yet ripe for SRFIzation...
> >
> > - Exceptions
> > - Binary I/O
> 
> SRFI 69 constitutes my take on "binary I/O."  (If opportune, what we
> consider for R6RS can be restricted to the imperative layer.)  Given
> that I've been the one-person-subcommittee on I/O, I suggest that any
> initial activity on the subject takes place there.
> 
> -- 
> Cheers =8-} Mike
> Friede, V?lkerverst?ndigung und ?berhaupt blabla
> _______________________________________________
> R6RS mailing list
> R6RS at iro.umontreal.ca
> http://mailman.iro.umontreal.ca/mailman/listinfo/r6rs
> 

In Boston we agreed that for binary I/O we require few features.  We
started off with read/write of an octet, and then added bulk I/O of a
group of octets, and this required adding vectors of octets.  This was
deemed sufficient.

So what I propose is that R6RS include the u8vector part of SRFI 4, i.e.

  (u8vector? obj) 
  (make-u8vector n [u8value]) ; u8value = 8 bit unsigned exact integer
  (u8vector u8value...) 
  (u8vector-length u8vect) 
  (u8vector-ref u8vect i) 
  (u8vector-set! u8vect i u8value) 
  (u8vector->list u8vect) 
  (list->u8vector u8list) ; u8list = list of u8values

and the external representation #u8(1 2 3 4).

The following I/O procedures would be added to R6RS:

  (read-u8 [port])
     => returns a u8value or the end-of-file object

  (write-u8 u8value [port])
     => writes a u8value, result unspecified

  (read-subu8vector u8vect start end [port])
     => reads octets into the section of u8vect between start and
        end (using the same indexing as substring) and returns the
        number of octets that were read or the end-of-file object
        when at end-of-file

  (write-subu8vector u8vect start end [port])
     => writes the octets in the section of u8vect between start and
        end (using the same indexing as substring) and returns the
        number of octets that were written

Note that the API for read-subu8vector and write-subu8vector
is able to support non-blocking I/O in an implementation of Scheme
that has that concept (possibly in R7RS?).  For a non-blocking
port, the integer returned could be less than end-start.

As for port creation procedures, no new procedures are required.  A
port (as created by open-input-file, etc) would be viewed as a stream
of octets and read-u8 and write-u8 would impose a character encoding
on that stream of octets (either in an implementation defined way or
in a fixed encoding defined by R6RS, say utf8).  To allow
implementations to buffer the characters, R6RS would restrict the use
of the port to either text I/O or binary I/O (i.e. if the first
operation on the port is a character I/O operation, then the binary
I/O operations on that port become undefined, and vice-versa for
symmetry reasons).

Although this was not one of the requirements, we could go further and
allow the specification of the character and end-of-line encoding of a
port when it is created.  This could be done with the API I suggested
in one of my recent emails, i.e.

   (open-input-file (list path: "foo" char-encoding: 'utf16-le))

but I sense that this is controversial, so I'm willing to drop it for
the sake of reaching concensus on I/O.

Marc



-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/