Re: (r6rs io ports)

[Mike Gran]

Hi-

> From: Ludovic Courtès address@hidden

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

It would be easier.  When thinking about this, I was remembering or
mis-remembering that, back in the 2009, you'd said some along the
lines of ultimately standardizing on the R6RS ports codebase, and that
I was to consider the work on Guile legacy ports as interrim.

So, I suppose, all along, I've been thinking that ultimately we'd end
up with something like I suggested, with the code in r6rs-ports.c
being the source of the major port functionality.

If these days we like how the Guile legacy ports are performing and
want to build R6RS ports on them, that's comparitively easy.
In which case...

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

Works for me.  Some questions that will have to be answered.
Is there a C API for raising R6RS error conditions?  
Do we need to raise Guile legacy errors when accessing ports through
the legacy API and R6RS errors when accessing ports through the 
R6RS API?
What about R6RS buffering modes?

Thanks,

Mike