Hi Mike,
Mike Gran <spk...@yahoo.com> writes:
> 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...
Heh, good point. I don’t like the current port API: it’s low-level,
it’s C, it’s undocumented, it forces users to access Guile internals,
etc. But it’s widely used, in Guile and outside. If (rnrs io ports)
were to be included in 2.0 (though I don’t think it should be a
showstopper), it would seem safer to choose a solution that is simple
and mostly orthogonal to the rest of Guile core.
Perhaps the move to a new port API (probably based on that of R6RS) can
be left for 2.2? Hopefully, we’ll be much less relying on C by then,
which should make things easier.
What do you think?
>> 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?
No, not yet. Actually, Julian’s work on R6RS libraries isn’t merged
yet.
> 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?
Ideally, yes, but it may be hard or impossible. Needs to be
investigated.
> What about R6RS buffering modes?
Something along these lines:
(define-syntax buffer-mode
(syntax-rules (none line block)
((_ none) _IONBF)
((_ line) _IOLBF)
((_ block) _IOFBF)))
(define* (open-file-input-port filename
#:optional options buffer-mode
maybe-transcoder)
(let ((f (open-input-file filename)))
(setvbuf f buffer-mode)
f))
(With disjoint types, exception conversion, etc. :-))
Thanks,
Ludo’.
