Re: [Axiom-developer] Re: bootstrap Meta/Boot

[M. Edward (Ed) Borasky]

Gabriel Dos Reis wrote:
> "Bill Page" <address@hidden> writes:
> 
> | On 8/9/07, Tim Daly wrote:
> | >
> | > In the IBM/NAG days you needed a running Axiom to build Axiom.
> | >
> | 
> | I believe that is one of the things that allowed Axiom to become so
> | advanced so quickly (relatively speaking). Axiom's library code is
> | highly circularly-dependent as a result. This structure makes Spad a
> | very expressive language indeed. (Probably even more expressive than
> | Python by most common measures.)
> 
> It is odd to state, but Axiomatizers should not underestimate the
> power of abstraction. 
> 
> Not because the whole system is mechanically translated to assembly
> code means that the system should actually be written in assembly
> code.  Think Unix, think C.  Think Spad, think high level.
> 
> Fortunately, Boot is already written in Boot and we have a 2-3 stage
> Boot-strap. 
> 
> -- Gaby

As a user who can't quite find the time to get involved with Axiom on a
deeper level, I must say I find the plethora of languages in the Axiom
development scheme quite daunting. Let's see: there's Axiom, Boot, SPAD,
Aldor *and* Common Lisp, not counting the underlying C that most of the
Common Lisps are built in. If *I* were building Axiom from "scratch",
I'd start with Common Lisp, because Common Lisp compilers are pretty
good. Then I would implement the core of Axiom in Common Lisp -- just
enough so it can bootstrap itself.

I think two levels of abstraction is probably the maximum a developer
should have to deal with, and one level would be even better. Of course,
any sufficiently powerful language is going to need a "virtual machine /
run time library" to handle OS interfaces, handling primitive data such
as strings, multiprecision numbers, floating point arithmetic, dense
arrays of floating point values, graphics, etc. while providing
reasonable efficiency and portability. But does it really need so many
sub-languages?