Re: [Axiom-developer] vmlisp

[Waldek Hebisch]

>   I understand the historical need for vmlisp.lisp -- which has now
> grown out of its original purpose.
> 
>   In 2007 where we are working towards ANSI Lisp based, is there a
> fundamental reason why we should still have the package VMLISP
> separate from the BOOT package?
> 
>   More specifically, I would like to move most of the content of
> VMLISP into BOOT, and minimize the size of the current web.  
> 

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.
OTOH packages are main Lisp tool to organize code and we should
make better use of them.  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.

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

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.

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

-- 
                              Waldek Hebisch
address@hidden