Re: (r6rs io ports)

[Ludovic Courtès]

Hi Mike,

Mike Gran <address@hidden> writes:

> First, let me note the ways that r6rs ports and Guile legacy ports are
> different:
>
> 1.  Encoding is a property of the port vs a property of a transcoder
>
>     R6RS have transcoder objects that describe a conversion as well
>     as the state of the conversion.

I wonder what the implications of having the conversion state in the
transcoder are.  For instance, what if the transcoder is shared among
several ports?  What if it’s passed from one port to another in the
middle of a conversion?

Section 8.2.4 of r6rs-lib says that transcoders are “possibly stateful”,
but it also says that they are immutable.  So I guess a possible
implementation is to have transcoders stateless and immutable, e.g.,

  (define (latin-1-codec)
    "ISO-8859-1")

  (define* (make-transcoder codec #:optional eol-style handling)
    (list coder eol-style handling))

If that is the case, implementing them on top of Guile’s ports should be
easier.  (The only thing is that there’s no distinction between binary
and textual Guile ports.)

>     These can be attached to ports or removed from ports.
>
> 2.  Pushback vs lookahead
>
>     Guile legacy ports implement an ungetc operation.  You can
>     always push a character back onto a port, even if the underlying
>     port doesn't support it.  It does this by implementing a
>     pushback buffer for each port.  Characters that are 'ungotten'
>     go into the pushback buffer, and the next getc checks the
>     pushback buffer first.  The pushback code is rather complex.
>
>     This behaviour is vital to operation of the legacy Guile parser,
>     which uses 'ungetc' repeatedly.
>
>     (I suppose this would allow Guile to parse code from a pipe,
>     but, I've never tried that.)
>
>     R6RS ports instead have the concept of 'lookahead' but no
>     'ungetc'.  Characters can not be pushed back onto a port, but,
>     one can lookahead to see what bytes or characters are next.

Guile has ‘scm_peek_char ()’ and ‘lookahead-u8’ is implemented in terms
of it in libguile/r6rs-ports.c.

> Anyway.  On to implementation...
>
> There are 4 types of R6RS ports: file, bytevector, string, and custom.
> Each port is either binary or textual, and not both at the same time.
>
> So one possibility is the following....
>
> 1. Expose scheme functions that are a set of low level file operations
> that bypass Guile legacy ports and scm_getc.
>
> 2. Build the binary R6RS port system in Scheme using these functions,
> and the bytevector and string functions that already exist.
>
> (There will be no pushback buffer or intermediate storage of port data.
> If a file supports random access or rewind, the lookahead operation will
> succeed.  Otherwise, it will fail.)
>
> 3. Create a transcoder object in C that holds encoding and conversion
> strategies, similar to those that we have attached to Guile legacy
> ports.  Add methods to the transcoder object to do conversion between
> bytevectors and strings.
>
> 4. Build textual R6RS ports in Scheme on top of the binary R6RS port 
> system and the transcoder object.
>
> 5. And, ultimately, create a 'pushback buffer' object that supports
> an ungetc operation.  Rebuild Guile legacy ports as a combination 
> of R6RS ports and a pushback buffer object.

I may well be missing something, but how about this hopefully simpler
strategy:

  1. Transcoders are (roughly) as simple as suggested above.

  2. In r6rs-ports.c, when a transcoder is passed, just
     scm_set_port_encoding_x, etc. the port.

  3. Implement EOL handling in Guile ports.

  4. See whether/how binary and textual ports can be differentiated in
     Guile ports.

  5. Have fun making sure the functions raise the right R6RS error
     conditions instead of ‘system-error’ et al.

How much sense does it make?  :-)

Thanks,
Ludo’.