[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.