<br><br><div class="gmail_quote">2009/9/1 Drew Crampsie <span dir="ltr"><<a href="mailto:drewc@tech.coop">drewc@tech.coop</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">2009/9/1 Gustavo <<a href="mailto:gugamilare@gmail.com">gugamilare@gmail.com</a>>:<br>
><br>
><br>
> 2009/9/1 Drew Crampsie <<a href="mailto:drewc@tech.coop">drewc@tech.coop</a>><br>
>><br>
>> 2009/9/1 Gustavo <<a href="mailto:gugamilare@gmail.com">gugamilare@gmail.com</a>>:<br>
>> > Hello,<br>
>> ><br>
>> > I also like to keep things simple. Here are a few suggestions, though.<br>
>> ><br>
>> > In paragraph 4, you didn't mention "sockets" explicitly in the list. I<br>
>> > don't<br>
>> > know if that is intended to be included in "Networking", because Unix<br>
>> > sockets are local to the computer.<br>
>><br>
>> To be quite honest, i don't know if CLtL3 actually needs sockets or<br>
>> networking. If we have FFI and extensible streams, we can build<br>
>> sockets and networking as library code.. right? I'm interested in<br>
>> hearing dissent on this one.<br>
><br>
> Well, yes, but all implementations that I know about have some interface to<br>
> sockets. So, I believe that this is a very small task for implementors, it<br>
> is just a matter of creating a small layer on top of them (like usocket) or<br>
> changing the functions that deal with them. Isn't Cltl3 meant to avoid the<br>
> need for portability layers?<br>
<br>
</div>Yes, avoiding portability layers is a goal.. so when you state " it is<br>
<div class="im">just a matter of creating a small layer on top of them (like<br>
</div>usocket)", we're directly against that goal. usocket and the like<br>
exist already, so there's not much value in working to standardize the<br>
interface... just use usocket! :)<br></blockquote><div><br>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?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I'm not sure what you mean by 'changing the functions that deal with<br>
them' in this context, but a goal of cltl3 (i will add this to the<br>
charter) is to require as little effort on the part of implementors as<br>
possible. In the case of sockets and networking, we can provide<br>
library code from a single source... so why duplicate that effort<br>
across every distribution or implementation of lisp? Seems like a<br>
wasted effort and a barrier to adoption from my POV.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
It is possible, given FFI and gray streams, to implement sockets<br>
without using _any_ implementation defined socket code. Rather than a<br>
compatibility layer that attempts to paper over the differences in<br>
implementations (trouble with such layers being a large motivation for<br>
the creation of CLtL3), i'd prefer a single canonical implementation<br>
based on constructs provided by CLtL3.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
The prior art here (as for a lot of things we will be discussing) is<br>
IOlib. IOlib uses its own implementation of sockets and networking<br>
based on the OS's underlying implementation (through FFI). It is<br>
mostly portable and uniform across implementations, and does not<br>
require any support for networking in the implementation itself<br>
(fe[nl]ix had better correct me if i'm wrong).</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> Maybe we could make the support for sockets optional for each<br>
> implementation, but standardize the interface for sockets for<br>
> implementations that want to provide them (something like "These functions<br>
> may signal an error if the implementations doesn't have support for<br>
> sockets.").<br>
<br>
</div>This is exactly what i'd like to avoid.</blockquote><div><br>Fair enough. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

[snipped]<br>
<br>
I'm still not dismissing inclusion of networking and sockets, but i've<br>
not heard a convincing argument for them, and i think our time would<br>
be better spent elsewhere.<br></blockquote><div><br>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".<br>
<br>Well, I guess I am the one playing the devil's advocate now :)<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
[snipped bit about hash tables]<br>
<div class="im"><br>
> I believe that we could discuss it later, when we discuss the CDR documents<br>
> (we are going to do that, aren't we?).<br>
<br>
</div>You bet. :)<br>
<br>
Cheers,<br>
<br>
drewc<br><br></blockquote><div><br>By the way, a few more topics that can be discussed:<br><br>* Features (as in trivial-features - e.g. when should x86-64 or x86 or darwin features be provided)<br>* (Per-package ?) Readtables (I believe we <b>really</b> should discuss about readtables, it would avoid many of the hacks that are needed for using read macros - clsql is the canonical example)<br>
* 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 <a href="http://www.sbcl.org/manual/Global-and-Always_002dBound-variables.html#Global-and-Always_002dBound-variables">sb-ext:defglobal</a>, 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).<br>
</div></div>