[Axiom-developer] RE: algebra Makefiles with explicit dependencies, bootstrap, fixe d-points etc.

[Page, Bill]

Tim,

On Tuesday, January 04, 2005 8:29 AM you wrote:

> ... 
> ASSUMING WE HAVE NOT CHANGED THE SIGNATURE OF a
> then b will still compile and be valid code

Are you saying that the *only* reason that the Axiom
)compile needs to "Load" .o files is just in order to
get the signature? Nothing else in the .o file affects
the code that gets generated?

> 
> Now if we try to change the signature of a
> so that it breaks b then we need to rewrite
> b into B and recompile it with A loaded so we
> start from scratch with
> 
> a'.lsp -> a.fasl
> b'.lsp -> b.fasl
> (load a)
> (load b)
> a  -> a.fasl
> b  -> b.fasl
> a  -> A
> A  -> A'.lsp -> A.fasl
> (load A)
> b  -> B
> B  -> B'.lsp -> B.fasl
> (modfify .spad file bootstraps thus:
> \section{A}
> A
> \section{A.bootstrap}
> A'.lsp
> 
> \section{B}
> B
> \section{B.bootstrap}
> B'.lsp
> 

It is possible (isn't it?) that these changes could
cascade down to all dependent and sub-dependent domains.
That is, a new signature passed to some domain could
cause another new signature (possibly different from
the first one) to be generated in a dependent domain
that must in turn be passed on to those domains that
are depended on it.

> and now we rebuild the system from scratch
> and it all works.

Are you sure that a single rebuild is sufficient?
How can you be sure that all dependent domains have
been properly re-compiled with the new signature.

> Notice you have to co-modify a -> A, b -> B in the
> same image and update the .spad file and bootstrap
> code before rebuilding from scratch.
> 
> Note that modifying a->A so it breaks b and
> simultaneously modifying b->B so it breaks a
> is left as an exercise. This kind of programming
> is what got axiom into the state where it needed
> a running axiom to build axiom.

I think that that is not so unnatural a state to be
in. As we have discussed before, one needs a running
C compiler in order to modify an re-compile the compiler.
If you then re-compile the new compiler source with the
new version of the compiler do you then get the same
object file as the one generated with the previous
version of the compiler?

This can happen in any system that is sufficiently
complex that it can be used to describe itself. I think
it is very natural that this happens in a computer
algebra system since exactly this sort of issue had been
addressed by mathematicians since the time of Kurt Godel.

> 
> Once you get past the circular dependency 
> problem you no longer have a need for the
> lisp bootstrap code. It is possible to modify 
> non-bootstrap code and break the system build
> but that's just a simple programming problem.
> 

I don't understand this point of view.

> It is very tricky to modify the fundamental
> cycles but it can be done. It has always been
> true that you need a running axiom to rebuild 
> axiom. My key breakthru was to make it possible
> to build axiom from scratch. However it is not
> true that you can randomly modify anything and
> expect the algebra to build.
>

As far as I understood what you did, Tim, I thought
that it just involved identifying a set of code modules
that if removed from the dependency graph, would result
in all the cycles being broken. Having done this, it
was then possible to sort the resulting lattice of
dependencies into layers of code modules that could be
compiled in sequence.

For those code modules that were logically removed from
the dependency graph you had to provide the lisp code
that had been generated by a previous running version of
Axiom. This is what you called the bootstrap.

Really you have not made it possible to build axiom from
scratch, i.e. from the spad files alone. The bootstrap
lisp code plays an essential role and it still can not be
derived from the spad files without a previously existing
running version of Axiom.
 
> In general you would like the makefile to know
> the dependency graph of algebra code. However
> you'll find that make can't handle such a graph.
>

That is true. 'make' will chase down the dependency
graph starting with whatever node(s) you specify until
it finds that it is about to loop back on itself. At
which point it will issue an warning that the specific
dependency what would have caused the loop is going to
be ignored. In other words, it breaks the cyclic
dependency in exactly the same way that you did Tim.
The only difference is that 'make' does not automatically
provide a bootstrap mechanism.
 
> I tried another idea which was to decorate each
> stanza from layer n with a ${LAYER(n-1)} but that
> fails also.

Do you recall what was the failure in that case. It
seems like it should work to me, except of course it
would not really be as useful as the full set of
dependencies. (I.e. many more dependencies would be
ignored than is really necessary.)

> 
> However the fact that I failed is no reason not
> to try because you  have a deeper understanding
> of make so I'm willing to be convinced. My general
> approach, when domain signatures change, is to do
> 
> make clean
> make
> 
> The algebra hierarchy needs a future rewrite for
> 2 reasons, Provisos and ACL2 integration. Hopefully
> we'll be smarter next time.
> 

Working with Axiom always makes me wish I was smarter.
In lieu of that, it seems to me the next best policy is
to try to use the smartest tools available to help us
do the job. This too is in keeping with the over all
philosophy of Axiom and computer mathematics, what is it
that we are trying to do if it is not some kind of mental
prosthesis?

Regards,
Bill Page.