Re: [Axiom-developer] Boot

[CY]

On Sunday 01 October 2006 21:42, root wrote:

> thus it seems there are 2 boot languages implemented (but not defined).
> my belief (but i don't remember) is that the src/boot directory came
> into being as part of the process of switching to the new boot/shoe
> language.

Yipe.  This makes the cmucl port all the more interesting, in that it doesn't 
have a boot directory.  I wonder how he pulled this off?  Was some of the 
boot dir logic merged in?

> you'll notice that the makefile in the src/boot directory explicitly
> translates using the BOOTSYS image which contains the 'shoe' parser.
> the makefile in the src/interp directory explicitly translates using
> the DEPSYS image which only contains interpreted lisp files from
> the interp directory and is NOT the same as the boot/shoe version.

Scary.

> rather than referring to them both as boot perhaps we should call
> the one in the src/boot directory 'shoe', following bill's convention.

I suppose I should know better than to ask, but since the eventual goal is to 
move the interp to Lisp anyway would a viable alternative be to "decode via 
rewrite?"  I'm rather intimidated by the idea of trying to understand a set 
of files written in either of two versions of an unspecified language - 
mightn't it be more efficient to understand what they were trying to/did 
achieve (without necessarily following all of the subtle details) and then 
doing that using more "modern" coding conventions and documenting how it is 
being done this time?  We might lose some optimizations initially but at 
least we would have clean, documented, modern code to work with.

When I took a run at getting Axiom going on sbcl, I was more or less able to 
get the boot dir code working - at least, boottocl ran.  But when I tried to 
get the cmucl port going, I seemed to run head on into some of the "Axiom 
wasn't designed with Lisp packages in mind" phenomena.  I was reading the 
Davenport high level overview of the Axiom system this weekend, and I can't 
help thinking that maybe the way to go is to identify these key "top level" 
features and think about how they might be implemented today.  For example 
(and this might be crazy, it's just a thought) wouldn't it be possible to use 
packages and the use/import/shadow concepts to handle some issues related to 
things like subdomains?  Have the SPAD language create a new package when a 
new subdomain is created, :use the API from the parent domain, :export the 
key functionality of the new domain, and if some more efficient algorithm 
exists for something implemented more generally in the parent domain :shadow 
the implementation from the parent domain and define a new, optimized 
implementation?

I'm afraid if we focus too hard on maintaining/duplicating exactly what the 
original Axiom code is doing, we're going to weave ourselves a very tangled 
web indeed.  Boot, shoe, and spad ALL lack a formal definition, and as such 
we are more or less in the position of deducing the language from the code.  
Eeek.  Shouldn't we be specifying what the language SHOULD be, and then 
re-merging the code into the new framework?

I could be wrong of course, but at the moment poor Tim seems to be in the 
position of being the keystone and most of the arch as well.  He's one of a 
VERY few people with a hope of decoding this as is, especially issues like 
optimization.  Is there any way the rest of us could do something that would 
make decoding the whole of the maze unnecessary?

CY