bloody list .. always forget to cc
---------- Forwarded message ---------- From: Drew Crampsie drewc@tech.coop Date: 2009/9/1 Subject: Re: [cltl3-devel] RFC: CLtL3 Charter To: Gustavo gugamilare@gmail.com
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?
Yes, avoiding portability layers is a goal.. so when you state " it is 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! :)
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.
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.
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).
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. If we have a portable implementation based on the simple constructs we plan to describe in CLtL3, we remove the need for implementors to support (or not support) our idea of what a socket library could be. We have no need to standardize an interface that implementors must support when we can write a portable interface. We can still call it 'standard' if you like, but 'standard library' and not 'cltl3', whatever that means :).
CLtL3 should be for things that _cannot_ be implemented portably, first and foremost. Sockets and networking _can_ be, on operating system that support them, via FFI. The goal of CLtL3 is to create a lisp where it is possible to have portable networking code, but not necessarily to include that code in the language itself... The line between 'library' and 'base language' was heavily blurred during the ANSI process... i'd prefer not to repeat that (what i view as a) mistake.
CL pathnames are the perfect example of what happens when you try to lowest-common-denominator these kind of things, and that's all we'd be able to do if we relied on existing implementation support. Going the other way, and expecting implementors and vendors to conform to our idea of what socket code should be is just as useless because, well, they won't.
Simply asked : what exactly do we gain by requiring a socket and networking layer as part of the base language, as opposed to in the library we plan to build on that language? If all you want is a uniform API, a standard library will have that. Heck, if you want that, code against IOlib!
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.
[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
(l) Weak Pointers, Weak Hashtables and Garbage Collector (like in trivial-garbage).
Right, i was just thinking about these last night. added.
And, by the way, "omission" have only one "m".
Damnit... i've been spelling that word wrong my entire life and just found out now! thanks :)
Thank my Firefox's spell checker :)
One more suggestion: you could add this sentence or something similar (after paragraph 4):
"Other topics might be discussed in the course of the description, but priority will be given to the topics mentioned above."
This way we can choose to discuss lesser details later.
drewc
cltl3-devel mailing list cltl3-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel
-
Drew Crampsie