Re: [Axiom-developer] Translation of the interp to lisp

[C Y]

--- root <address@hidden> wrote:

> > 1.  Where is the most current work on that translation?  Is it in
> > the silver/gold branches?  Or one of the tla archives?  (Sorry if
> > I missed this in my archive hunt - there were a lot of emails on
> > the general subject).
> 
> the current work is on my local disk. the first fruits are in 
> bookvol5.pamphlet. i'm currently working on decoding the interface
> between the parser and the rest of the system (ptrees, pf2sex). 
> this is the place where the input syntax gets turned into
> s-expressions and will give us a clue about how to modify the input
> language.

OK, thanks.
 
> > 2.  I noticed a lot of implementation specific code having to do
> > with things like (system:getenv $AXIOM) - is the plan to write
> > some generic macros to handle these operations and get all of the
> > implementation specific logic into one file?
> 
> yes, there are a lot of #+ and #- blocks of code laying around.
> these are gradually being collected into bookvol5 and generalized.

OK.  Those blocks will be important for portability - sbcl, for
example, is quite different on the system interface than GCL (sbcl
doesn't even have a system package - the relevant logic appears in
sb-posix.)  I would suggest hiding that logic behind macros collected
into a single section/chapter/whatever, and then when someone tries to
port it to a new platform they can start be defining all the macro
logic for their own platform.  

> it appears that you are trying to get axiom running in ansi (say,
> sbcl).

Well, let's say I was experimenting to see how difficult it would be. 
It would be very nice to have the lisp logic contained in an asdf file,
and avoid the need for separate make logic for the lisp files.  I think
such a file could probably be constructed from the debugsys file, but
for a good job of it I would like to break things up into modules and
other logical units, which requires a deeper understanding than I have
achieved as yet.

> one possible path is to use the debugsys.lisp file and try
> loading it into sbcl. for each failure, modify the original pamphlet
> file. eventually you'll have an set of lisp files that load. at that
> point you can try running some of the input files thru the ansi
> image.

Yes, that looks like the quickest approach.  If I were to do this
though, it could result in a disconnect with the boot.pamphlet files -
changes I make at a lisp level might be hard to map back into the
original logic.  I guess it could be done, but it might be a slow cycle
- I'd have to change the boot file, then recompile everying to
re-generate the lisp files and see if the change was the correct one. 
If I use the int files, that is - I tried taking a run at the main src
tree and ran into the problems with bootstrapping boot.  One of the
things that will definitely need to be changed, right off the bat, is
things like the LISP and USER packages -> CL and CL-USER.

One question Tim - if I'm reading the doc correctly, the build process
actually creates three lisp images - the bootstrap image, the defsys
image, and then the final one.  Is this because the bootstrap code
can't live in the same image with the final code due to conflicts?

> if they succeed you can diff the pamphlet files and post the patches.

OK.  Should this be targeted at the boot level (when we get the basic
lisp files loaded) or the boot code?

> once we have an idea of the ansi differences the next task will be
> to either try to get it running in GCL again or move the system onto
> sbcl.

I think we will want to be able to run on GCL - it's probably the best
deployment target for Windows at the moment.  What we might do instead,
though, is shift from the Ctl2 image to the ANSI image.  I know GCL
isn't all the way to ANSI yet, but maybe our moving there will help
that process along :-).

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com