On 13-Apr-06, at 9:01 PM, Ben Goetter wrote:

> Marc Feeley wrote:
>> After rereading this part of your message I think I may have
>> misunderstood you.  Do you mean that the procedure's signatures
>> should explicit the type of port to indicate the type constraints?
> That's right.  I'm also arguing for separate procedures for opening
> a byte port vs a char port.

Can you explain why you think this is necessary?

As far as I can tell, conceptually you want (for input ports):

   (open-char-input-file path) -> char-only-input-port
   (open-byte-input-file path) -> byte-only-input-port

and you view char-input-port and byte-input-port as distinct types.
That is read-char requires a char-only-input-port and read-byte
requires a byte-only-input-port.  Please correct me if this is wrong.

SRFI 91 provides:

   (open-input-file path) -> byte-input-port

and both read-char and read-byte are supported on byte-input-ports.
So you don't "lose" any feature with SRFI 91, since you can get what
you want with:

   (define open-char-input-file open-input-file)
   (define open-byte-input-file open-input-file)

But with SRFI 91 you do gain the ability to mix reading bytes and
reading characters on the same port.

Marc