[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (r6rs io ports)

From: Ludovic Courtès
Subject: Re: (r6rs io ports)
Date: Sat, 10 Apr 2010 20:14:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Hi Mike,

Mike Gran <address@hidden> 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

> Do we need to raise Guile legacy errors when accessing ports through
> the legacy API and R6RS errors when accessing ports through the 

Ideally, yes, but it may be hard or impossible.  Needs to be

> 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
    (let ((f (open-input-file filename)))
      (setvbuf f buffer-mode)

(With disjoint types, exception conversion, etc. :-))


reply via email to

[Prev in Thread] Current Thread [Next in Thread]