[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Axiom-developer] letting my mud settle
From: |
C Y |
Subject: |
RE: [Axiom-developer] letting my mud settle |
Date: |
Tue, 8 Nov 2005 13:54:54 -0800 (PST) |
--- 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
- RE: [Axiom-developer] Terms of Surrender (was: BAD tim), (continued)
- Re: [Axiom-developer] Terms of Surrender (was: BAD tim), William Sit, 2005/11/07
- Re: [Axiom-developer] Terms of Surrender (was: BAD tim), C Y, 2005/11/07
- Re: [Axiom-developer] Terms of Surrender (was: BAD tim), William Sit, 2005/11/07
- Re: [Axiom-developer] Terms of Surrender (was: BAD tim), C Y, 2005/11/07
- [Axiom-developer] letting my mud settle, root, 2005/11/07
- Re: [Axiom-developer] letting my mud settle, Jay Belanger, 2005/11/08
- Re: [Axiom-developer] letting my mud settle, C Y, 2005/11/08
- RE: [Axiom-developer] letting my mud settle, Bill Page, 2005/11/08
- RE: [Axiom-developer] letting my mud settle,
C Y <=
- RE: [Axiom-developer] letting my mud settle, Bill Page, 2005/11/08
- RE: [Axiom-developer] letting my mud settle, C Y, 2005/11/09
- [Axiom-developer] bootstrapping (was: letting my mud settle), Bill Page, 2005/11/09
- [Axiom-developer] Bootstrapping, C Y, 2005/11/09
- [Axiom-developer] RE: Bootstrapping, Bill Page, 2005/11/09
- [Axiom-developer] RE: Bootstrapping, C Y, 2005/11/09
- Re: [Axiom-developer] RE: Bootstrapping, Andrey G. Grozin, 2005/11/10
- RE: [Axiom-developer] RE: Bootstrapping, Bill Page, 2005/11/10
- RE: [Axiom-developer] RE: Bootstrapping, C Y, 2005/11/10
- [Axiom-developer] security and trust in Axiom (was: Bootstrapping), Bill Page, 2005/11/10