2009/9/1 Drew Crampsie
<drewc@tech.coop>
2009/9/1 Gustavo <
gugamilare@gmail.com>:
>
>
> 2009/9/1 Drew Crampsie <
drewc@tech.coop>
>>
>> 2009/9/1 Gustavo <
gugamilare@gmail.com>:
>> > Hello,
>> >
>> > I also like to keep things simple. Here are a few suggestions, though.
>> >
>> > In paragraph 4, you didn't mention "sockets" explicitly in the list. I
>> > don't
>> > know if that is intended to be included in "Networking", because Unix
>> > sockets are local to the computer.
>>
>> To be quite honest, i don't know if CLtL3 actually needs sockets or
>> networking. If we have FFI and extensible streams, we can build
>> sockets and networking as library code.. right? I'm interested in
>> hearing dissent on this one.
>
> Well, yes, but all implementations that I know about have some interface to
> sockets. So, I believe that this is a very small task for implementors, it
> is just a matter of creating a small layer on top of them (like usocket) or
> changing the functions that deal with them. Isn't Cltl3 meant to avoid the
> need for portability layers?
just a matter of creating a small layer on top of them (like
usocket)", we're directly against that goal. usocket and the like
exist already, so there's not much value in working to standardize the
interface... just use usocket! :)
Well, maybe I didn't expressed myself clearly. And I didn't quite get your point. If you go down that road, we could say that we don't need to standardize FFI or threads as well ("just use CFFI or bordaux-threads" - usocket is just as much of a portability layer as CFFI or bordeaux-threads is). In the part of "just create a small layer on top of them", I meant internally in each implementation. Each implementation will take the functions to manipulate sockets that it already has and create the standard functions on top of them or make small modifications appropriately to make those functions conform with the standard. This is what I believe that will be done by implementations to conform FFI, thread and any other standard we create here, isn't it?
I'm not sure what you mean by 'changing the functions that deal with
them' in this context, but a goal of cltl3 (i will add this to the
charter) is to require as little effort on the part of implementors as
possible. In the case of sockets and networking, we can provide
library code from a single source... so why duplicate that effort
across every distribution or implementation of lisp? Seems like a
wasted effort and a barrier to adoption from my POV.
My point is that every implementation already support sockets, it should be much better if there was a standard interface so they could implement socket interface uniformly across implementations.
It is possible, given FFI and gray streams, to implement sockets
without using _any_ implementation defined socket code. Rather than a
compatibility layer that attempts to paper over the differences in
implementations (trouble with such layers being a large motivation for
the creation of CLtL3), i'd prefer a single canonical implementation
based on constructs provided by CLtL3.
I believe it would also be possible to implement multiple threading that way (using FFI, if it support callbacks (as CFFI does)). But I'm not going further on this topic.
The prior art here (as for a lot of things we will be discussing) is
IOlib. IOlib uses its own implementation of sockets and networking
based on the OS's underlying implementation (through FFI). It is
mostly portable and uniform across implementations, and does not
require any support for networking in the implementation itself
(fe[nl]ix had better correct me if i'm wrong).
Using IOlib has its drawbacks. It is a big library, one more dependency and it will only add functionality that is already present in all Lisp implementations. It also uses grays streams, which are not optimized streams (so implementation specific's sockets should be faster for good implementations). And it uses FFI, which is a barrier when you need to save and load lisp images.
> Maybe we could make the support for sockets optional for each
> implementation, but standardize the interface for sockets for
> implementations that want to provide them (something like "These functions
> may signal an error if the implementations doesn't have support for
> sockets.").
This is exactly what i'd like to avoid.
Fair enough.
[snipped]
I'm still not dismissing inclusion of networking and sockets, but i've
not heard a convincing argument for them, and i think our time would
be better spent elsewhere.
I still can't really see why standardizing sockets is so different from other topics that were included. I agree with you when you say our time will be better spent in other subjects for now, but I really think we should discuss this at some point. Lack of standard sockets is one of the topics that are most oftenly mentioned when the subject is "what are CL's negative points".
Well, I guess I am the one playing the devil's advocate now :)
[snipped bit about hash tables]
> I believe that we could discuss it later, when we discuss the CDR documents
> (we are going to do that, aren't we?).
You bet. :)
Cheers,
drewc
By the way, a few more topics that can be discussed:
* Features (as in trivial-features - e.g. when should x86-64 or x86 or darwin features be provided)
* (Per-package ?) Readtables (I believe we
really should discuss about readtables, it would avoid many of the hacks that are needed for using read macros - clsql is the canonical example)
* Declarations and other optimizations - For instance, ECL has a declaration to freeze some generic function to avoid redefinition or including new methods, which is used for optimization. Freezing functions and types may be useful as well. Something like a standard
sb-ext:defglobal, including sb-ext:global and sb-ext:always-bound proclamations, are welcome. I don't know if these are good ideas, but it would be very simple and easy to both include and implement (since actually using the declarations is optional, and defglobal can be implemented as an usual defvar).