axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] vmlisp


From: Gabriel Dos Reis
Subject: Re: [Axiom-developer] vmlisp
Date: Sun, 13 May 2007 10:23:39 -0500 (CDT)

On Sun, 13 May 2007, Waldek Hebisch wrote:

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

The motivation of moving VMLISP to BOOT is not that we have too many
packages. This has nothing to do with Lisp package mehcanism.
The motivation for merging both is that we end up with codes that
do not know where to pick their symbols from, duplicate definitions in 
both packages, and more confusion.  Codes that are so tied should be in one
logical unit.

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

some observations:

   (1) the problem is not that initial-env.lisp is a bad idea.  The 
       problem is that is contains some codes that may be of use only
       to bootsys, and not the rest of the compiler.

       However, it is a good idea to have initial-env.lisp as a central
       place to put things that we use over again and again --
       the interface to the build machinery.  Note also tha initial-env.lisp
       was a quick setup that had me started on another front of Axiom code
       reorganization.

       I started last night moving bits and pieces that are only bootsys
       specific to Boot codes.

   (2) In the long run, bootsys should be integrated to the final
       AXIOMsys image


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

vmlisp.lisp and macro.lisp contains lot of things that have nothing to do with
the Axiom VM proper.  But, I agree that we should have a logical unit
for the Axiom VM.

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

I have nothing against that, as long as we understand what the old code is
doing and we can prove/convince each other that removing the old code is
the good way forward.  I would propose that code removal be subject to 
discussion so that we have a public record of each others' understanding.

-- Gaby




reply via email to

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