One's "excursion in «intelligent» impudence" is another's striving to understand the internals of some system or another. Hate is especially cheap when it's gratuitous, what can I say.

AFAIK there's no obstacle to adding raw syscall support to SBCL and passing in raw octet arrays for params. Could then handle it a la "M". But will still have to get the constants and struct layouts somewhere, per platform.

I think what I'm trying to go towards is that reimplementing the socket interface at all the possible levels (POSIX, CL, usocket etc.) half-assedly like that is a bad idea, and that the (Common?) Lisp implementation shouldn't burden the user with supporting yet another such layer. I understand they wanted to make it easier, but in the process they've somehow managed to achieve the opposite, I'd much rather work with naked pointers than with what SBCL has now.

> To my eye, the problem is that the system call interface should be a first-class citizen in any CL running on Unix, and preferably not through C library calls.

The annoying bit here is that the kernel expects platform-specific structs and magicnumbers for many syscall parameters. See e.g. my UDP lib for a concrete example.

It is certainly possible to construct these on the fly and without the use of the C stdlib, or for that matter GCC per se (see e.g. example in my "M" experiment) but then must determine the magicnumbers manually, per platform.

Huh, it seems that did the trick, thanks! So now the only fiddling one needs to do with constants.lisp is adding the actual socket options.

> I'm curious whether a spelunk into the Clozure CL internals would leave you with the same bad taste in your mouth.

That sounds like a great idea, I'll take a look. In fact since I'm there, I might as well look into the other ones, at the very least to get an idea how the networking interface changes across CL implementations; though I'm not sure that's the issue. To my eye, the problem is that the system call interface should be a first-class citizen in any CL running on Unix, and preferably not through C library calls. That may be too much of me to ask, but even a sane 1-to-1 mapping between implementation-specific CL constructs ("socket streams" or whatever) and the actual POSIX interface would be a great feature.

I've been concerned about SBCL ever since a core maintainer ridiculed the idea of signing releases with a GPG key years ago. I wouldn't be surprised if SBCL is as haphazard as any other open source volunteer-supported turd. I'm curious whether a spelunk into the Clozure CL internals would leave you with the same bad taste in your mouth. It appears to be written by a consulting firm, i.e. folks that actually have to make money by being productive on the damned thing.

Lately I trust nothing that doesn't have good money flowing through it.