Re: [cltl3-devel] RFC: CLtL3 Charter
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.
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.
(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 :) drewc
Cheers, Gustavo.
2009/8/31 Drew Crampsie <drewc@tech.coop>
Hello all,
Below is a draft of the charter for the CLtL3 project. Please comment as you see fit.
Cheers,
drewc
Purposes of the CLtL3 effort. SECOND DRAFT - 2009-08-31 -
1) The CLtL3 group wishes to create an updated description of Common Lisp. It should codify existing practice and provide additional features to facilitate portability of code among diverse implementations.
2) The group intends the description to be a base for a larger "standard library" of code. The focus of the effort will be to provide library authors with a stable and portable lisp on which to build an evolving distribution that meets the ever changing needs of modern developers.
3) The group will begin with ANSI Common Lisp as described in the _Common Lisp Hyperspec_. All possible effort will be made to ensure source compatibility. The group does not intend to remove any functionality from the language, and will only deprecate features that are superseded by those in CLtL3.
4) The group will address the following topics in the course of producing the description. Preference will be given to topics that cannot be implemented portably and have multiple existing implementations.
(a) Repairing mistakes, ambiguities, and minor ommissions in ANSI Common Lisp (b) Extensions outlined in the CDR (including the MOP) (c) Multiprocessing and Concurrency (d) Foreign Function Interfaces (e) Extensible Streams (f) Extensible Sequences (g) Networking (h) OS and Filesystem access (i) Editing and Introspection
5) The CLtL3 effort will be a community effort.Discussion will take place on public forums. Any source code or documents produced will be placed under a permissive open source license that also allows commercial use and redistribution.
_______________________________________________ cltl3-devel mailing list cltl3-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel
On Tue, Sep 1, 2009 at 6:21 PM, Drew Crampsie<drewc@tech.coop> wrote:
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.
I've only been working with CL for 6 months so take all my opinions with that in mind.. but I think not having native sockets / networking is a big minus for a language in this day and age. To a relative beginner like me, having to use FFI (I know what this is but have never touched it myself) and extensible streams (I don't really have a concrete idea of what these entail, is it in any way similar to Java *OutputStream classes?) just to write to the network seems like quite a lot of hoops to jump through as opposed to just using some standardised functions. And I understand the situation now is that there are a plethora of networking libraries, which no doubt causes confusion when coming to the language for the first time... I think forcing implementations to include network code which you can rely on to be maintained and debugged is a big win. Cheers, Malcolm
2009/9/1 Malcolm Reynolds <malcolm.reynolds@gmail.com>:
On Tue, Sep 1, 2009 at 6:21 PM, Drew Crampsie<drewc@tech.coop> wrote:
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.
I've only been working with CL for 6 months so take all my opinions with that in mind.. but I think not having native sockets / networking is a big minus for a language in this day and age.
Section 2 of the charter mentions a 'standard library', which will include sockets and networking code. It is a lot easier, as a community, to ship a library than it is implementation-specific code. You, as a user, would use the 'standard library' and not care.
To a relative beginner like me, having to use FFI (I know what this is but have never touched it myself) and extensible streams (I don't really have a concrete idea of what these entail, is it in any way similar to Java *OutputStream classes?) just to write to the network seems like quite a lot of hoops to jump through as opposed to just using some standardised functions.
As a user, you would not need to write your own networking library just to use the network.. library implementors would do this for you, as they do now. The fact is that current implementations build their networking code on the equivalent of FFI and extensible streams, so that's all that really needs describing (read 'standardised') in order to build a portable sockets/networking library.
And I understand the situation now is that there are a plethora of networking libraries, which no doubt causes confusion when coming to the language for the first time...
The goal of the CLtL3 project is not to make the language easier for those using it the first time, it's to provide a solid foundation for library authors and promote portability among implementations. Many things in CL are confusing to newcomers, and it is not our expressed goal to change this. Rather, the goals of CLtL3 are to provide enough of a "Common Lisp" base language so that things like networking libraries and the like may be implemented using portable constructs rather than implementation-specific ones. As a newcomer, this may not seem as important to you has using the same network library as everyone else, but from those trying to provide that networking library, it's extremely important... vital even.
I think forcing implementations to include network code which you can rely on to be maintained and debugged is a big win.
"forcing implementations" is not something we want or plan to do. We rather hope to keep things simple enough that the cost of adoption for implementations is a minimal as possible. If we have to force implementors to do anything, we'll have lost the battle before it's even begun. For a new user like yourself, it's not going to matter if networking is in CLtL3 or the 'standard library' whatsoever. For an implementor, not having to support all that extra code in the library is a big plus and lowers the barriers to adoption... they can just ship CLtL3 compatibility, and let us worry about the 'standard library'. Which do you think is better, many implementations of the same protocol scattered among lisps, or a single-sourced library built on portable constructs that have been provided by each implementation? My opinion is that the latter is likely to provide a better user experience with less effort to implementors than the former, and hence more likely to see wide adoption. I'm playing devil's advocate to a certain extent, so please don't take my arguments as a brushing off of your needs. I'm interested in hearing rebuttals and more dissent, but the goals expressed in the charter must be kept in mind... keeping CLtL3 small and simple is the only way it's going to work, and if we can remove the need to describe something large and complex like networking and sockets, we'll have a better chance of actually achieving something rather than just arguing about it :). Cheers, drewc
Cheers,
Malcolm
Section 2 of the charter mentions a 'standard library', which will include sockets and networking code. It is a lot easier, as a community, to ship a library than it is implementation-specific code. You, as a user, would use the 'standard library' and not care.
Okay, this is sounds good. Essentially my point would come down to "it should be easy to do networking in CLtL3" and if the path of least resistance is to standardise FFI and streams then that definitely makes sense. I definitely appreciate your point about it not necessarily being about making CL easier for newcomers, as clearly a lot of the complex and initially confusing stuff is what, in the end, makes it a good language. As long as the end user experience of writing network code is (approximately) as simple as in newer scripting languages, I agree that whether you're using a standard library or standardised language features makes no odds, and so the approach of keeping it simple in order to make for an easy (ish!) standardisation process is the right choice. Malcolm
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<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
On Wed, Sep 2, 2009 at 1:47 AM, Gustavo<gugamilare@gmail.com> wrote:
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?)
Indeed, the approach followed by Christophe Rhodes in his extensible sequences paper is much more appropriate. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
Hi, Am 01.09.2009 um 19:21 schrieb Drew Crampsie:
2009/9/1 Gustavo <gugamilare@gmail.com>:
<snip>
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.
Having had to deal with this recently, I think having at least whats in CLtL2 would be great. I might be wrong, but I'm not sure you can build an full AST - like in cl-walker or arnesi - with the technique used in macroexpand-dammit. Although its cool what the macroexpand- dammit author has done, it doesn't strike me as very elegant and 'the way you would want to do it'. Although some people in the IRC channel have the opinion that "there is nothing you truely need a walker for", I think this view is too limited/ignorant. I believe there are (many) valid use cases like code introspection/analysis ... How does this relate to the "Editing" features meantioned in the draft charta. Cl-walker not only uses environment augmentation (as in CLtL2 environments), but also environment introspection. I'm not sure how much more effort it would be to include environment introspection (both defining a good interface and adoption for implementors) and I very much agree with you that for CLtL3 to be successful at all it must be as brief and small as possible. On the other hand environment access is (unlike say sockets) not something that can be done as part of the "standard library". Having said that I think environment access is not of the highest priority but should be discussed. Lisp is all about giving you access to the compiler and I can't see a reason why this shouldn't be the case for environments. The rationale of not including the CLtL2 environments in the ANSI standard would be interesting here.
<snip>
participants (5)
-
Drew Crampsie -
Gustavo -
Luís Oliveira -
Malcolm Reynolds -
Nikolaus Demmel