<br><br><div class="gmail_quote">2009/9/1 Drew Crampsie <span dir="ltr"><<a href="mailto:drewc@tech.coop" target="_blank">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;">

2009/9/1 Gustavo <<a href="mailto:gugamilare@gmail.com" target="_blank">gugamilare@gmail.com</a>>:<br>
<div>> 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 don't<br>
> know if that is intended to be included in "Networking", because Unix<br>
> sockets are local to the computer.<br>
<br>
</div>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></blockquote><div><br>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 <a href="http://common-lisp.net/project/usocket/" target="_blank">usocket</a>) or changing the functions that deal with them. Isn't Cltl3 meant to avoid the need for portability layers?<br>
<br>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.").<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><br>
><br>
> A few more topics that could be discussed:<br>
><br>
> (j) Interface to Environments, which is needed in a macro walker (e.g.<br>
> cl-walker accesses lexical environments using implementation specific<br>
> functions).<br>
<br>
</div>I'm interested in this as well... but macroexpand-dammit shows one<br>
doesn't need environments to do a portable walker. However, most lisps<br>
have CLtL2 environments at least, so i'll add this to the list.<br>
<div><br>
> (k)Custom Hash Functions and Hashtable Test (SBCL's extensions).<br>
<br>
</div>This is covered by a CDR, and so is on the list already.<br></blockquote><div><br>I know, but I didn't like the approach of that CDR. I think that the standard functions gethash, make-hash-table, etc, should work for generic hashtables, no new packages should be needed. It also should specify how the type (or class) GENERIC-HASH-TABLE should be related to the system class HASH-TABLE (Is it a subtype? A proper subtype? Or a disjoint type?) or to other types. Well, it even didn't define such a type, but I think we shoud. I believe that we could discuss it later, when we discuss the CDR documents (we are going to do that, aren't we?).<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><br>
> (l) Weak Pointers, Weak Hashtables and Garbage Collector (like in<br>
> trivial-garbage).<br>
<br>
</div>Right, i was just thinking about these last night. added.<br>
<div><br>
> And, by the way, "omission" have only one "m".<br>
<br>
</div>Damnit... i've been spelling that word wrong my entire life and just<br>
found out now! thanks :)<br></blockquote><div><br>Thank my Firefox's spell checker :)<br><br>One more suggestion: you could add this sentence or something similar (after paragraph 4):<br><br>"Other topics might be discussed in the course of the description, but priority will be given to the topics mentioned above."<br>
<br>This way we can choose to discuss lesser details later.<br>
<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>
drewc<br></blockquote></div><br>