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

Re: Why are byte ports "ports" as such?

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.