2009/9/1 Drew Crampsie
<drewc@tech.coop>
2009/9/1 Gustavo <gugamilare@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?
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.").
>
> A few more topics that could be discussed:
>
> (j) Interface to Environments, which is needed in a macro walker (e.g.
> cl-walker accesses lexical environments using implementation specific
> functions).
I'm interested in this as well... but macroexpand-dammit shows one
doesn't need environments to do a portable walker. However, most lisps
have CLtL2 environments at least, so i'll add this to the list.
> (k)Custom Hash Functions and Hashtable Test (SBCL's extensions).
This is covered by a CDR, and so is on the list already.
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?).
> (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