gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Roadmap


From: Lou Glassy
Subject: Re: [Gcl-devel] Roadmap
Date: Sun, 26 May 2002 13:41:11 -0600

Camm-

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
              changed.

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 
GCL-2.5.0.

Next:

4.  (your #6)  Is this Rainer Joswig's creation?  I am not sure what this,
               exactly...?  Does the current GCL code suffer from memory
               corruption, generally?

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
       other stuff.
       
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
  German!

--

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)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]