guile-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Split r6rs-ports.c according to module boundaries


From: Mark H Weaver
Subject: Re: [PATCH] Split r6rs-ports.c according to module boundaries
Date: Tue, 19 Nov 2013 02:53:40 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Hi Andreas,

This new patch has a very serious problem, which was not obvious at
first glance.  We've made some significant improvements to r6rs-ports.c
since you first introduced this patch, and this new patch would
effectively undo all of them.  It's a good thing I took the time to
check.  Please be more careful.
 
Apart from that, a few other issues:

* The commit message says:
  > * libguile.h: Add #include for "libguile/r6rs-ports.h".
  You added "libguile/binary-ports.h" not "libguile/r6rs-ports.h".

* The new binary-ports.c includes r6rs-ports.h.  Can binary-ports.c
  include binary-ports.h instead?  If so, I think it should.

* I'm not sure that r6rs-ports.h should include binary-ports.h.
  Currently, r6rs-ports.h is only included by two files:
  r6rs-ports.c and deprecated.c.  I think that deprecated.c
  should be changed to include binary-ports.h, and r6rs-ports.c
  should include both.

* The new binary-ports.c includes two procedures that accept a
  transcoder argument: 'open-bytevector-input-port' and
  'open-bytevector-output-port'.  What happens when we implement
  transcoders (which I'd like to do fairly soon).  Will it be a problem
  that transcoders will be in a separate module now?

I confess I'm not entirely clear on why this module is being split.  It
seems to me that this whole thing is the R6RS ports API.  Can you help
me understand the reason for this split?

     Thanks,
       Mark



reply via email to

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