Email list hosting service & mailing list manager


Re: Sockets Layer Counter Proposal Aaron W. Hsu 30 Oct 2012 05:49 UTC

On Sun, 28 Oct 2012 19:14:20 -0400, John Cowan <xxxxxx@mercury.ccil.org>
wrote:

> My UDP-specific proposal at
> <http://trac.sacrideo.us/wg/wiki/DatagramChannelsCowan>, has two
> constructors, make-datagram-channel for socket() followed by bind() and
> make-output-only-datagram-channel for just socket().  I believe this is
> a better division of labor than the standard one.

I would argue that this breaks the idea of having a procedure for creating
sockets that can create sockets of any type and family. To follow this
through you would need a new maker procedure (two, actually) for every
single socket type, which hurts scalability and extensibility. Moreover, I
would make the additional claim that this new paradigm, whether or not it
is actually better, is not worth deviating from the underlying sockets
paradigm, which is already well established. It is one thing to change or
alter the names of things to match more closely to the conventions of the
language, it's another to change the underlying API.

> Like R[67]RS call-with-port, it makes sure the socket is closed if proc
> terminates normally, a non-trivial difference.

Okay, in this case I fail to see the reason for the explicit socket
argument. I do think that the automatic closing could be useful, but in
the form specified by 106 I think it's too awkward and annoying to use.
I'd probably prefer:

   (call-with-socket domain type protocol thunk)

> IMHO "unix" (which is a trademark) should be suppressed in favor of
> "local"
> in all these names.

I agree with favoring the ``local'' variation, but I think the unix name
should be kept around as an equivalent.

--
Aaron W. Hsu | xxxxxx@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the Lost Art of Thinking.