RE: [Axiom-developer] letting my mud settle

[C Y]

--- Bill Page <address@hidden> wrote:

> I am not aware of any of Tim's past sins -- only his present
> ones. ;) Building Axiom from sources only, which was apparently
> a requirement imposed by restrictive licensing conditions which
> apparently prevented any of the previously commercial binary
> versions of Axiom to be distributed along with the Axiom source
> code, was certainly a challenge because of the way that Axiom
> had been designed to be "bootstrapped" from an existing running
> copy. But this is no different than the situation with most
> compilers and in particular GNU C (gcc).

Personally, I would be happier with a system that can be bootstrapped. 
I know at some point you need a compiler to make a compiler unless you
want to feed binary into the machine by hand (which happened at some
point in the remote mists of computer past) but I have always disliked
the idea of needing a running program in order to build new versions of
that program.  You are implicitly trusting a binary when you do that,
and I like the idea of a system being completely buildable from source
code.  I suppose the realization of that in reality would require a
hardware compiler for some minimalistic language.  Hmm...  I wonder how
hard it would be to design a printed circuit board that compiles
lisp... ;-)

> I think that William Sit is right that having accomplished this
> bootstrap, it seems unnecessary to continue to distribute Axiom
> in this way. It is now quite possible to return to the way Axiom
> used to be distributed as binary code plus source code. Building
> open source Axiom would then require a running version of open
> source Axiom in exactly the same way that building gcc from
> source code requires a running gcc.

What about a platform that has no running Axiom binary?  gcc, IIRC,
solves this by a rather convoluted process called cross compilation? 
It would be nice not to have to worry about such issues for Axiom - why
not keep the design goal of building Axiom using only a working ANSI
Lisp?

> Since this thread is at least partly devoted to "airing dirty
> laundry", I should mention that in retrospect I think the specific
> way in which Axiom algebra was bootstrapped from source, i.e. by
> including machine generated lisp code from Spad compiler output
> directly in the pamphlet files was probably not the best idea.

Well, a cleaner solution would be nice, but hopefully rewriting the
source in Lisp would allow us to unknot this situation.

> At the time Tim made this decision I was not really part of the
> project and even if I had been I would not have understood then
> that there was a better way. But now it is clear to me that the
> cyclic dependencies in Axiom's library code are a result of the
> fairly extensive use of mutual recursion, i.e. source modules
> that naturally recursively depend on each other.

This bothers me in principle.  Why is this necessary?  I for one would
prefer to change this situation, if it can be changed.  Chicken-egg
situations are seldom desirable.

> This may not have been especially obvious even to the original 
> Axiom developers since Axiom had always previously been built from 
> an existing running version of Axiom and the algebra code as written
> over a fairly long period of time.

I worry about a case in the future in which the Axiom code might have
to be built without any working binaries of Axiom - what happens then? 
We've already seen the pain this situation caused once.

> In theory the better way, instead of patching in the lisp output
> of a previous version of Axiom, would have been (and which still
> may be) to compile Spad "stub" files consisting only of the initial
> code with all dependencies removed, for those Spad files which
> had been specially selected to break the dependency cycles - or
> for that matter, even compiling all existing Spad files - first
> as "stubs' and then a second time in their full source form.

If a "stub" file satisfies the dependancy requirement, is there really
a circular dependence in the first place?  Maybe I'm not understanding
how that really works.
 
> We have previously discussed this extensively as part of the
> thread:
> 
> http://wiki.axiom-developer.org/17AlgebraBOOTSTRAPFixedPoint
> http://wiki.axiom-developer.org/MutualRecursion
> 
> I think that recognizing this is important because it is
> really a **feature** of the Spad language and the Axiom algebra
> library in particular. It is not a *problem* as such, but rather
> a challenge for the compiler developers. Aldor at least partially
> addresses this through it's "extend" mechanism.

Circular dependence is a feature?  I'm afraid I'm not following, if I
understand you correctly - how can this be an advantage?

> > the task at this time is to document it and clean it up.
> 
> I think as Tim will admit, that task is still at it's beginning
> stage. Very few (maybe less than 10%) of the Axiom source code
> pamphlet files currently contain any useful documentation besides
> the comments contained in the original code. And even to get this
> far Tim has had to devote a lot of time and effort to just creating
> the amount of documentation that does exist and is essential to
> building Axiom from the current source distribution - especially
> in the make files.

Tim, is the plan to retain the ability to build from source only in the
future? 

> > i need to get to the point of being able to say 
> > 
> >   (compile-file "interpreter.lisp") ; actually bookvol5
> >   (load "interpreter")
> >   (compile-file "compiler.lisp")    ; actually bookvol6
> >   (load "compiler")
> >   (compile-file "browser.lisp")     ; actually bookvol7
> >   (load "browser")
> >   (compile-file "graphics.lisp")    ; actually bookvol8
> >   (load "graphics")
> >   (axiom)
> > 
> 
> To me this vision of how to build Axiom seems terribly myopic.
> I don't think it addresses the really important issues about
> Axiom's design. And more over, getting a stage where something
> like the above build sequence might be possible is likely to
> both distract from the all important task of documentation plus
> lead us away from some of the things that really need to be
> documented most, e.g. the relationship between Spad, Boot and
> Lisp.

Perhaps a lisp rewrite with documentation occurring along the way will
address all of these concerns, depending on how it is done.

Cheers,
CY


        
                
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com