--- Bill Page <[EMAIL PROTECTED]> 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 _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
