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

Marc Feeley scripsit:

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

Rather than a design in which byte ports *are* character ports,
I'd prefer a design in which character ports are *constructed from*
byte ports.  Advantages:

	Byte ports do not have to carry about character-port
	attributes such as encodings, so they are more lightweight;

	Character port attributes can be immutable, since if
	you don't like the current character port, you can ask
	for a new character port on the same byte port
	(this requires a character-port procedure to return the
	underlying byte port if any);

	Character ports that aren't backed by byte ports are
	not a special case.

In order to do mixed-mode I/O, you require unbuffered character
ports, though the underlying byte ports can be buffered or unbuffered.
(In any case, I'd like to see evidence that buffering characters
as opposed to bytes is a Good Thing.)

Where the wombat has walked,            John Cowan <cowan@ccil.org>
it will inevitably walk again.          http://www.ccil.org/~cowan