[cltl3-devel] RFC: CLtL3 Charter

[Gustavo]

2009/9/1 Drew Crampsie <drewc at tech.coop>

> 2009/9/1 Gustavo <gugamilare at gmail.com>:
> >
> >
> > 2009/9/1 Drew Crampsie <drewc at tech.coop>
> >>
> >> 2009/9/1 Gustavo <gugamilare at 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! :)
>

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<http://www.sbcl.org/manual/Global-and-Always_002dBound-variables.html#Global-and-Always_002dBound-variables>,
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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090902/a18d38d1/attachment.html>