[cltl3-devel] Fwd: Comments on recent mail

[Drew Crampsie]

forgot to CC the list :

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


2009/5/15 Daniel Weinreb <dlw at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel
>