[cltl3-devel] RFC: CLtL3 Charter

[Gustavo]

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<http://common-lisp.net/project/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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090901/2aa36720/attachment.html>