[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Roadmap
Re: [Gcl-devel] Roadmap
Sun, 26 May 2002 13:41:11 -0600
I don't know who the larger world of GCL users is - so take the
following with a few grains of salt... My own point of view of GCL
is as a general-purpose Lisp programmer. I don't use Maxima, but if
there is a population of GCL/Maxima users out there, then I think we
want keep GCL fully functional as a Maxima substrate. For myself, I
use GCL for my dissertation work in optical character recognition.
I might order the 11 items in the development roadmap in the following
way (most important things first):
1. (your #9) clean builds with -Wall.
2. (your #8) resize memory image sizes for typical use. The current defaults
seem OK for my use, but if different sizes work better for
the majority of GCL users, I'm happy to have the defaults
3. (your #10) cleanup licensing questions for newly-engulfed lisp code.
After doing these three things, I'd say we're ready to go public with
4. (your #6) Is this Rainer Joswig's creation? I am not sure what this,
exactly...? Does the current GCL code suffer from memory
5. (your #4) automake-based Makefile system.
6. (your #2) ANSI CL compliance and CLOS. There is a portable CLOS
system that CMUCL used to use (they may still, I'm not sure.
It's called PCL. This might be the shortest route to
getting CLOS into GCL.
7. (your #11, #1) See Cliki (http://ww.telent.net/cliki). Would UFFI
help here? Interoperability with other ANSI CL implementations
use would be a good thing.
8. (your #7) Performance enhancements. I'd recommend getting it
right first, then getting it to go faster.
9. (your #3) ECLS. If the projects could merge, that'd probably be a
good thing; we'd have more eyes looking at the same code.
As far as the Boehm GC goes, I'm a little dubious about this.
It doesn't seem to offer any functional advantage over the
mark-sweep collection we already have. The first important
trait a GC subsystem should have, is that it shouldn't leak.
Secondly, once it doesn't leak, it should be fast. Well, Boehm
GC does leak -- and this is a known characteristic of
conservative garbage collectors. The leakage is small, and for
many applications, bounded, but ...
There are cases where conservative GC simply *cannot* safely
sweep up memory. From what I've read, the usual side-effect of
using Boehm GC is that your runtime memory footprint goes up by
(say) 10%. Now, this 10% hit may or may not be unacceptable -
you'd also have a GC subsystem that has been relatively
well-maintained, which would free up our time for working on
10. (your #5) 64-bit ports. This is not a hot item for me, personally.
On your #11 (is GCL useful?) - I'd say, YES. GCL's useful because
it's GNU, if for no other reason. From a technical standpoint, there
are faster free CL implementations; ones that are way ahead of GCL in
terms of ANSI CL compliance, ones with a richer set of bindings for
various C-ish libraries, etc. etc. But GCL is the one Common Lisp
implementation that is really a GNU thing, as opposed to a Linuxish
project at Sourceforge. I would use it if for only that reason.
But from a useability standpoint, I've found GCL is as good or better
than the competition:
* We use info for on-line help. There are some really neat things we
can do with this, in the future.
* GCL is fairly simple to install (at least on Unix hosts). CMUCL and
SBCL are nightmares to install, by comparison.
* The GC we use, while not state-of-the-art, has the advantage of being
proven. CMUCL's generational GC, in practice, is a lot slower than GCL's.
* The codebase is something I can *read* --- CLISP's source is probably
well-commented; but that doesn't help me much, since I don't read
I'm hoping to have some time to actually help work on GCL, in the near
future. I greatly appreciate the work Bill Schelter put into GCL, and
all the work you and the rest of gcl-devel have put into it since
Bill's untimely SIGSEGV.
Lou Glassy (address@hidden)