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

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

This page is part of the web mail archives of SRFI 91 from before July 7th, 2015. The new archives for SRFI 91 contain all messages, not just those from before July 7th, 2015.

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.