Re: [Axiom-developer] vmlisp

[C Y]

--- Waldek Hebisch <address@hidden> wrote:

> I think that Lisp code in Axiom needs substantial cleanup.  There
> is a lot of duplication (even more than in .boot files).  It is
> likely that 50% or more of Lisp code is unused or duplicated.

I wonder if there are Lisp utilities somewhere that could identify
unused code for us.  Hmm...

> OTOH packages are main Lisp tool to organize code and we should
> make better use of them.

DEFINITELY agree.

> From my point of view just moving
> symbols from VMLISP into BOOT gains us nothing -- intead of two
> closely tied piles of code we get one pile which is as closly
> tied as before.

Agreed.
 
> I would like to see Lisp code reorganized along the following lines:
> 
> 1) Portability wrappers and general purpose utilities.  This should
>    abstract away most differences between Lisp implementations.

YES.  This is a must for all large Lisp projects.  I suggest we also
make use of widely used libraries already out there so we don't wind up
duplicating work already done in this department (if the license is
compatible with Axiom, we can include it in the tarball and
conditionally load it based on the capabilities of the target build
Lisp system - if it already has it great, if not we've got it in the
tarball.)  We might also (eventually) convert them into literate files
- dunno if the upstream projects would accept that, but we could
incorporate them.

Tools I would like to check out:
CL-FAD   http://weitz.de/cl-fad/      (portable pathnames)
usocket  http://www.cliki.net/usocket (portable sockets)

if we want to use threads, http://www.cliki.net/Portable-Threads
if we need FFI access, http://common-lisp.net/project/cffi/

>    File access and image dumping are prime examples of thing needed
>    there.  This should be a file (possibly multiple files) in 
>    src/lisp subdirectory and should be loaded into very first image
>    that we dump (so that we can use the exported functionality
>    during the whole build).  I think that this code deserves it
>    own package (possibly multiple packages).

Absolutely agree.  One question - why do we want to dump Lisp images
during the build again?  I think this was explained a long while back,
but I'm not recalling - it still seems odd to me :-(.
  
>   I noticed that you load inital-env.lisp from src/boot into the
>   first image.  I do not think it is a goog idea: inital-env.lisp
>   contains a lot of Shoe specific code and misses many functions
>   that are needed later (some of them could benefit Shoe).
> 
> 2) Axiom virtual machine: Lisp code needed to support output of
>    Spad compiler.  This part should depend weakly on host Lisp.
>    Large parts of macros.lisp and vmlisp.lisp should go there.

Sounds good.

> 3) Part of "normal" code which are written in Lisp, those should
>    live in src/interp and src/boot as apropriate.
> 
> I planned to start implementing part 1, but I have noticed that
> you are doing similar but different things in build-improvements.

Waldek, would it be possible for you to upload your "almost working on
sbcl" tree?  I'm working with sbcl mostly and it would be very handy,
even if it's not 100% correct yet.  Most of the tools of interest for
portability haven't worked their way around to GCL yet so that also
makes things difficult.

> I should say stress one point here: simultaneously with moving
> code around or implementing new functionality we should remove
> old code.

Agreed.  We want to avoid "dead" code and prune it out - it only makes
the system harder to understand.  Perhaps some of it can be made "live"
again but I'll bet a lot of it is dead for good.

Cheers,
CY


       
____________________________________________________________________________________Boardwalk
 for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's 
economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow