[cltl3-devel] RFC: CLtL3 Charter

[Gustavo]

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

> [snipped some context]
>
> >> 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.
>
> Right, i getcha, and i don't necessarily disagree. But, why require
> that an implementation have sockets when you don't need them to be
> implementation specific?
>
> Sure, given sockets you can create a crude FFI, but it will not be
> fast or pretty. However, the socket interface i can create via FFI and
> extensible streams is just as good, if not better, than those provided
> by individual implementations.
>
> What if i want more functionality for our sockets then those provided
> by an implementation? do i ask the implementation to implement my
> extension? Again, if we try to force implementors to do anything,
> we've lost. We need to gain traction and momentum first.
>
> The point i'm trying to make is that including sockets and networking
> in the CLtL3 specification (it's not a standard, lets not call it one)
> will require work, and potentially a lot of work, on both our parts
> and the parts of implementors. I see a good argument for excluding
> them (a perfectly good implementation can be built on the features we
> provide), but i've yet to hear a good argument for providing them (in
> the description rather than the library) beyond 'because some
> implementations have sockets already'.
>

All right, I guess you won this discussion. I won't die for not having a
per-implementation interface for sockets. I guess I did not had in mind that
implementors might or might not like Cltl3 and choose to comply with it or
not to care at all.

But, in any case, as I see in usocket's page, all currently alive
implementations that I am aware of (except perhaps Corman CL) have at least
the basics for sockets.

>

 [snipped]
>

> Thanks for all the feedback! Your input has been quite valuable so far.
>

You are welcome. I'm just having some fun.

There are still a bunch of minor things that could be be included in Cltl3,
but I don't know yet how much effort this might take, so this is just a
suggestion. Hooks (hooks for when the gc runs, for when Lisp initializes and
finishes (useful for when you save and load images and need to do some setup
or teardown) and possibly others). There are also functions like quitting
lisp, running an external program, access to a shell (like
trivial-shell<http://common-lisp.net/project/trivial-shell/>)
a way of getting the so-called "posix-argv". The last three might fall in
the "OS and Filesystem access" topic.

Cheers,
Gustavo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090902/078b4b5b/attachment.html>