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

Taylor R. Campbell scripsit:

> If we introduce this third object, then we can simplify the model of
> input and output ports very much, so that an input port is purely a
> source and an output port purely a sink, and we can specify any
> options common to the resource that they are both associated with on
> the third object; 

So you are proposing an incompatible change to R5RS?  Currently, both R5RS
and this SRFI duck-type input and output ports: they are not required to
be disjoint, though ports as such are disjoint from other R5RS objects.

> Continuing on the socket theme, port I/O doesn't even make sense for
> some sockets, such as stream listener sockets and unconnected datagram
> sockets.  In these cases it would be absurd to represent the socket as
> a port, while it makes very much sense to represent it as a distinct
> `socket' object, from which in certain cases (specifically, connected
> sockets) one can obtain ports.

I don't disagree with this, nor does this SRFI exclude it.

> I think this is actually a bad idea.  It's not entirely clear when the
> resource itself gets closed, versus when individual directions are
> closed.  CLOSE-PORT, it seems, cannot be defined as
> 
>   (define (close-port port)
>     (if (input-port? port) (close-input-port port))
>     (if (output-port? port) (close-output-port port))),
> 
> if it does more than just CLOSE-INPUT-PORT and CLOSE-OUTPUT-PORT;
> either that or both CLOSE-INPUT-PORT and CLOSE-OUTPUT-PORT must have
> complicated definitions in order to close the resource only if both
> directions are closed -- but even then that doesn't work very well
> with sockets.  

I don't understand this.  With a tty or similar bidirectional device-file,
closing the input or the output would have no effect unless the other were
also closed, a fact which can be remembered by two bits in the port object.
For sockets or ptys, input and output closing do the right thing, though
the two bits are still useful if you want to eagerly dispose of underlying
resources such as fds.  If you dispose of them lazily there is
of course no problem.

Entia non multiplicanda praeter necessitatem.

-- 
All Norstrilians knew what laughter was:        John Cowan
it was "pleasurable corrigible malfunction".    cowan@ccil.org
        --Cordwainer Smith, Norstrilia