Re: [Axiom-developer] lattice

[Gabriel Dos Reis]

"Page, Bill" <address@hidden> writes:

| Gaby, 
| 
| On Thursday, August 10, 2006 9:29 PM you wrote:
| > ... 
| > A project might be to have the compiler output spad
| > dependencies --
| > just like GCC is able to output dependencies, which greatly
| > facilitates the tedious part of writing Makefiles and
| > keeping them in sync; Automake uses it.
| > 
| 
| Where you here "years ago" when we first discussed the fact
| that Axiom's build dependencies form a digraph with loops?

I was probably not here; or I was here but not paying attention. :-/

| That makes the problem of using Automake rather more
| difficult, I think - not impossible, but one would still
| have to manually define a set of "bootstrap" modules which
| when removed from the graph, turn it into a lattice that
| can be sorted.

I don't expect to have Automake figure out the dependencies by itself.
However, I do expect that at some point, Axiom compiler should be able
to output the dependencies.  It may not be a simple task; but that is
the whole point!

| Tim Daly did this entirely manually as part
| of the initial steps in making Axiom available as open source.

yes; I understand that.  That must have taken him a good deal of resources.

| Prior to that it was always necessary to have a running
| version of Axiom in order to build Axiom - and that was
| considered by some people contrary to the intention of making
| Axiom "fully available" as open source (i.e. without also
| having to distribute a binary version).
| 
| Having software find a optimal minimal set of bootstrap
| modules is an interest (open?) question.

It is an ideal.  If we can't get it 100%, we must approximate to the
point where the residual is sufficiently small and manageable.

| What to actually do about the circular dependencies themselves
| is, perhaps a separate, but interesting subject in it's own
| right.
| 
| I am very interested in you opinions on this subject because
| of your background with gcc which also involves a bootstrapping
| process, although I think no circular dependencies, right?

Bootstrapping problems, by definition, involve circularities.

GCC, for example, provides a sufficiently ANSI C89-conformant compiler.
It is written in C.  Therefore we have a bootstrapping problem.
"Fortunately", there are many flavours of C.  K&R being the most
popular.  Well, you have to define which "K&R".
Consequently, GCC was written in K&R C, restricted or augmented as
appropriate.  But, the new stream of developers had ANSI C89
background, and very few knew the subtle differences between K&R and
ANSI C.  And even the experts that knew them got trapped from time to
time.  The result was hard-to-find miscompilation bugs.
Consequently, we decided to bit the bullet and require ANSI C89
bootstrapping compiler.  For the few remaining platforms (notably
some old HPUX) where the system compiler is not ANSI C89, there are
binaries people can download install.

The project I know that is close to Axiom's dilemma is the Glorious
Glasgow Haskell Compiler System (GHC).
GHC is written in Haskell and you need a Haskell compiler to bootstrap
it.  To facilitate porting to new platforms, they also problem
generated C files that people to compile with "C" to build a
boostrapping compiler.  They also distribute binaries.

Where we are now is a bit different from where Tim was four years ago.
We have to think about how to reduce the surface complexity (as would
say a friend of mine). We're not going to attract lot of people
because we try to make Axiom look complicated.  We can gain by making
it look simpler to use, simpler to understand, simpler to modify. 

-- Gaby