forgot to CC the list :

---------- Forwarded message ---------- From: Drew Crampsie drewc@tech.coop Date: 2009/5/16 Subject: Re: [cltl3-devel] Comments on recent mail To: Daniel Weinreb dlw@alum.mit.edu

2009/5/15 Daniel Weinreb dlw@alum.mit.edu:

Here are my opinions on the issues discussed in the recent mail.

Nikodemus's points are excellent.  For this effort to succeed, it must start small.  I also agree that it should be bottom-up.  It should start with existing, accepted libraries, and avoid innovation: experience has shown that it's usually unwise to standardize things that haven't been tried out pretty thoroughly.

I agree 100% with both Nikodemus and yourself on this point. We have to start small and actually achieve something rather than aim for the stars.

Jochen brings up the question of whether we want to standardize on official interfaces only, or on implementations as well.  CLtL itself attempted to describe all the functions, macros, etc. without saying anything about their implementation.  Here, there may be some conceptual tension between whether we are trying to define (more or) a langauge, establish a set of API's to libraries without saying anything about their implementation, or gather a useful common set of libraries.

Gathering a useful common set of libraries is a good start, but it's not enough. I'm going to use CLOS and LOOP of examples of things that could simply have been part of a collection of libraries, but were rather made 'part of the language', and the language is better for it (imo).

I personally think the best approach (for a start) is to establish a set of API's based on existing libraries, and work to document and integrate these extensions.

The Manifesto talks about "language extensions" at one point, and a "standard library" later on, which may lead to some confusion about this point.

This was intentional, as i see CLtL3 as both a core language, and a set of 'standard' libraries that use the core language. Something like Hunchentoot obviously does not belong in the core language, but it does require threads and sockets and extensible streams and unicode and ffi to function properly. I can see some value in distributing a set of libraries that are known to work together and all use the cltl3 versions of (threads sockets ffi etc) rather than the various existing libraries. This is not, however, an immediate goal of mine.

On the other hand, if you look at CLtL, you can see that it does not separate a "core language" from a bunch of functions and macros that can be build on that core language.  (That's a big reason that Common Lisp is criticized as being a language that's "too large". If you consider Java plus all the standard Java libraries, it looks big too!)  We had originally wanted to define CLtL that way, but it was too difficult, for many practical reasons.  So Common Lisp is left with a legacy of not distinguishing clearly between what is the "language" and what are "already-loaded standard libraries".

I think it will be useful to define a CLtL3 core distinct from the 'standard library' of code that runs on top of it. This core already includes ANSI CL, of course, + the language extenstions we can agree on.

This leads into the question of scope.  There are some things that are so basic, and so widely needed, and so small, that it's completely clear that they belong: a library for portable sockets (usocket), for example.  A way to write one's own streams is clearly a language extension, and one of the various stream packages should certainly be included.  It would be great to be able to have a standard way to deal with Unicode strings, although there are some thing that made that hard.  Thread manipulation is another obvious candidate.

I think that we can all agree that sockets, threads, streams, FFI and unicode are all in scope. I'd like to throw environment access on the pile (can't write a portable code-walker without it).

What I, myself, would like to see is easy ways for programmers to do all the normal things that application programs and servers can do today.  How much of that belongs in the scope of the CLtL3 process is yet to be determined.  We might agree that there should be easy and common ways to do an HTTP server, but also agree that CLtL3 isn't the place to put them.

I think it might be useful to define 3 different 'scopes', Core, Experimental and Library (and possibly a fourth, 'Contrib', after we ship and people build on that). Obviously, we should initially focus on Core, but i think that, having all these minds together, we shouldn't stop there :).

Sequences, along the lines that Christope Rhodes has started to do, would be great.  On the other hand, I think what he has so far isn't ideal and needs more develop'ment, and I'd be hesitant about declaring it a standard at this point.

I'd like to see extensible sequences in CL, but i can agree that without being widely used, something shouldn't be standard. The CLtL3 'Experimental' scope is perfect for such things... a 'Library' should feel free to use things in Experimental, as both Experimental and Library will be specified as unstable interfaces.

New ideas on packages and modules, while welcome, are something I'd consider too innovative to put into a "standard" library.  These thing are hard to invent and take a long time to get experience with.  I was one of the people who designed packges (yes, mea culpa) and I've been involved more than once in trying to come up with better modularity constructs, and I can assure you it's not obvious or easy.  Let's stick to what's well-understood for the foreseeable future.

I agree with you on the last point.. we have to keep it simple and stick to what we know, at least initially. Once we've gained some traction, and things in 'Experimental' are being used, that will hopefully lead to the experimentation and discussion that is needed to improve and eventually 'standardise' such things. Until that point, we should make sure that we are simply describing and gathering current best practices.

One of my first 'deliverables' for this project is a "CLtL3 Charter" along the lines of the x3j13 charter ( http://www.nhplace.com/kent/CL/x3j13-sd-05.html ). I think it will help immensely to have a document to point at and say 'this is what we're doing and how we're doing it'.

If we can come to a reasonable consensus on the initial focus of CLtL3, that would go a long way towards defining a charter :).

Cheers,

drewc

-- Dan

-- ________________________________________ Daniel Weinreb http://danweinreb.org/blog/ Discussion about the future of Lisp: ilc2009.scheming.org

---

cltl3-devel mailing list cltl3-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel