[cltl3-devel] Comments on recent mail

[Daniel Weinreb]

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'm sympathetic with what Peter Denno says, but I've been though
things like this before, and trying to "do the right thing" from the
beginning, in a project such as this one, often ends up stopping the
whole thing from happening.  We should start pulling things together,
and then try to move towards the more careful, professional practices
that Peter describes.

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.

The Manifesto talks about "language extensions" at one point, and a
"standard library" later on, which may lead to some confusion about
this point.  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".

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.

Then you can move up to thinks that are quite clearly libraries, yet
considered something that any system should not be without, such as
regular expressions.  Then there are XML libraries, an HTTP client, an
HTTP server.  There are some things where it's not clear what approach
is best, such as generation of web pages and interfacing to relational
databases, but we could pick one.

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.

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 development, and I'd be hesitant about declaring
it a standard at this point.

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.

-- Dan

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