Re: [Axiom-developer] Value stack overflow bug

[root]

Bill,

Sorry for the delay but I've been heads-down trying to get a
runnable Axiom version.

> > ... 
> > Unfortunately I've not yet solved the compile problem. 
> > Essentially the issue is as follows: It was always the case 
> > that you needed a running Axiom system to build a runnable 
> > Axiom system. I've been reworking the system to fix this (as 
> > most people don't have a running Axiom). In order for this to 
> > work you need to be able to bootstrap the Axiom compile 
> > process. So far, though I've flattened a dozen issues, this 
> > still remains unsolved.
> 
> It seems to me that it is conceivable that one might always
> need a running Axiom system in order to (conveniently) build
> a runnable Axiom system. This is essentially the case with any
> compiler that compiles itself. Most higher level languages are
> in this sort of situation today, e.g. the GNU C compiler (gcc)
> is written in gcc, right? Of course there might be the possibily
> of "cross-compilation", i.e. using Axiom on one platform to
> build Axiom on some other platform. And if you were really
> ambitious and had a lot of time, one might be able to re-implement
> the whole thing in some other language, e.g. the way the "Aldor
> part" of Axiom was re-written in C.

Technically Axiom can't be built from scratch at several levels
because it needs a Meta compiler, a Boot compiler, and an Axiom
compiler (and also a C and a Lisp compiler but they come free).
However, I've worked around most of the problems associated
with bootstrapping the system. Having such circularity is less than
ideal for several reasons not the least of which is that you wouldn't
be able to download sources and type 'make'. The whole system is
very close to being built from scratch. I've been bug-chasing the
remaining bugs but some are very deep and require days worth of
work (indeed, the last reported GCL ELT bug had me recursed 80
levels deep into the system. I thought my mental stack would
overflow :-) ).

> 
> A thought: Would using Aldor help to make a runnable Axiom
> system?
> 
> > 
> > This week I'm taking a different, temporary path. I'm 
> > building a working Axiom that can be freely distributed and 
> > is derived from the source code. However, it can't be built 
> > from the source code (yet). I hope to have it available this 
> > weekend. I'm doing this for 3 reasons. First, it will make 
> > Axiom available again. Second, it will allow users to 
> > generate bug reports (hopefully one of the bugs will give us 
> > the clue to the compiler problem). Third, some potential 
> > bright-spot of a developer might be able to help with the 
> > compiler bug.
> > 
> 
> What would be the problem if you were to take this approach
> as the primary path instead of just a temporary one?

If we were to pursue the aldor route I'd consider scrapping the axiom
interpreter and going to a compile-time only environment.  This has
been discussed several times and it is very, very hard.  Manuel
Bronstein has done some work on this path before.  I don't know of
anyone that would fund such an effort and I don't believe we would get
the research-level expertise for free.

But if I were to even entertain such a huge job (which, believe me,
I'm not) I'd go the other way and grind it all into common lisp
syntax. The ability of a program to read another program as data gives
a "second order" power that is hard in Axiom.

Tim Daly
address@hidden
address@hidden