Fwd: RFC: CLtL3 Charter
Drew Crampsie <
drewc@...>
2009-09-02 01:30:43 GMT
bloody list .. always forget to cc
---------- Forwarded message ----------
From: Drew Crampsie <drewc@...>
Date: 2009/9/1
Subject: Re: [cltl3-devel] RFC: CLtL3 Charter
To: Gustavo <gugamilare@...>
2009/9/1 Gustavo <gugamilare@...>:
>
>
> 2009/9/1 Drew Crampsie <drewc@...>
>>
>> 2009/9/1 Gustavo <gugamilare@...>:
>> > 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@...
> http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel
>
>
RSS Feed