[Gcl-devel] Roadmap

[Camm Maguire]

Greetings!  Just a few thoughts for discussion regarding the roadmap
to a 2.5.0 release.  Feedback is sought on which of these a) should be
pursued at all, and b) should be completed prior to a 2.5.0 release.

1) shared external libgmp support.
        Its now clear how this should be done -- we'd have to define a
        static array for bignum mallocs, like we do for the bfd struct
        malloced on bfd open, and wrap the gmp mul calls to precede
        them with a malloc function redirect to a function assigning
        this static space.  Pros: relieves us of the burden of syncing
        with gmp, can be used for other external libs calling malloc,
        should have no noticeable performance impact, Cons: have to
        carry a static space alloced by all executables big enough for
        reasonable usage, and failing if exceeded.  We already have a
        number of static stacks which cause an abort if filled, so
        this won't be terribly different.  But we really need to
        consolidate them into one big static area, instead of having
        many separate abort conditions on single function arrays.
        R. Toy mentioned, if I understood correctly, that CMULISP has
        a large such area for external function memory access which is
        kept separate from the lisp heap.  I still don't understand
        what the big issue is about *access*, if one can temporarily
        shut off gc, but this seems ideal/essential for external
        *mallocs*. 

2) Ansi-common-lisp compliance and compile-time test suite courtesy of
   clocc.

3) ecls -- I've been looking at our sister descendant of AKCL, and
   they have a number of interesting developments which we might wish
   to incorporate.  In fact, we really should merge the projects, as
   one of the *terrible* (IMHO) aspects about the lisp world is the
   system fragmentation.  
        a) having a shared library -llisp with all the lisp runtime
           stuff needed by executables.  It really seems
           unconscionable, even on large memory systems, to have so
           much unshared memory in lisp programs.  Does anyone else
           care about this, especially on multi-user systems?  It would
           be near impossible, AFAICT, to run a modern unix system
           which was written entirely in lisp for this reason.
        b) Boehm garbage collector option.  They seem to already have
           done the integration!  We could even make this runtime
           switcheable.         
        c) several gcl-missing lisp features provided.

In fact, I'd like to know what advantages gcl currently has, if any,
over ecls.  Bear in mind that I haven't used the system.

4) Modern/robust Makefile system based on automake.

5) 64bit ports

6) Incorporating Rainer's memory-integrity checking code as a
   debugging option. (Haven't looked at this yet).

7) Performance analysis, enhancement.  I'd really like to know where
   the bottlenecks are from those who use the system heavily.  Am
   already aware of gc as one.

8) Resizing default/initial memory image size to be more suitable for
   typical use.

9) Clean builds with -Wall.

10) Licensing -- we've added some new lisp code, which to my
    understanding is all gpl compatible.  But we need to double check
    and document.

11) External interfaces -- gtk bindings, blas/lapack bindings, etc.
    What if any are useful?

Any feedback on the above is much appreciated.  In addition, I'd like
some frank feedback on the following:

11) Is gcl useful?  Does it still provide something which isn't
    readily available in other systems?  I.e., frankly, is there a
    need or even desire for gcl to continue?  Developing the system is
    interesting, and even somewhat enjoyable, but it seems like a
    waste of effort if everyone would rather use something else.  If
    there are unique strengths of gcl, what are they?  What should we
    concentrate on to truly provide a needed service for users, rather
    than trying to simply catch-up to what is available somewhere
    else?   Please don't get me wrong -- I don't mind working on gcl
    at all, but I do want to be effective.

Take care,

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah