Re: [Axiom-developer] Turtles all the way down.

[root]

> Axiom's a pretty complex system, and it seems to have picked up a bunch
> of other projects like clef, noweb, and gcl, and like all good lisp
> systems,  even recursive project dependencies like gcl has it's own bfd,
> and gmp.
> 
> There is still a set of external dependencies that have to be satisfied,
> like pdflatex, gcc, and others.
> 
> The recent clef/readline thread points out it may be advantageous to
> review the list of internal and external dependencies, and prune some cod=
> e.
> 
> What are people thinking about the builds of axiom? Debian tries to
> patch axiom to use system supplied tools and libraries where possible,
> the Mac OS X port tries to use local copies of everything.
> build-improvements stated goals are to automagically pick up any
> installed copies and build the rest internally.
> 
> I ask because I had to mangle ./configure to fix a test for
> malloc/malloc.h on Intel Mac. Neither of the autoconf programs installed
> on my Mac like the configure.in in gcl-2.6.8pre:
> 
> $ /sw/bin/autoconf --version
> autoconf (GNU Autoconf) 2.60
> 
> $ /usr/bin/autoconf --version
> autoconf (GNU Autoconf) 2.59
> 
> configure says it's been generated with autoconf 2.13.
> 
> I guess there's really no way to ship axiom with it's own autoconf if we
> have any expectation of using configure to build axiom, but how far down
> do we plan to go? I saw Gaby is seriously considering integrating gcl
> and gcc.

Well this is a long running controvery with opinions ranging from
rewriting Axiom completely in Aldor to the current bundle (which
except for noweb, gcl, and latex) are all part of the commercial 
version, to the more extreme case of fully bundling GCL and noweb.

Since opinion varies widely on this it will continue to be debated,
which is the point, really.

I'm working from a philosophy that borders on the pragmatic with a
focus on the long term (the 30 year horizon). We need to try to invent
the environment and the organization of computational mathematics that
will be considered "state of the art" in 30 years For example, we
might consider a system that allows direct manipulation of
n-dimensional varieties.  This would correspond to the underlying
mathematics similar in spirit to current solid models based on
mathematical relationships such as spline curves or finite meshes.

In the middle term we need to critique the current methods (e.g.
textual literate programming) and seek out new methods (e.g video and
interactive tools).  We need to build prototypes of these ideas.  We
also need to consider ideas like Doyen, Sage, Scientific Linux, and
Knoppix Math (a Japanese effort).

In the short term the idea is to choose tools which achieve certain
goals (e.g.  noweb for textual literate programming), modified as
necessary to fit new ideas. Some of these tools are packaged along with
the axiom distribution in the zips directory.  Everything in the
repository outside of zips (and some inside of zips) is part of the
commercial axiom build or later developments. GCL even has other
systems packaged within it.

These short term tools have been the source of controversy for
various reaons. Axiom is not yet ansi common lisp but aspires
to that goal, at which point it should run in any common lisp
rather than just GCL. However, GCL was historically developed
specifically for Axiom by Bill Schelter under contract to IBM.
I worked with Bill on various aspects of GCL, thus making it
rather easy as a first target port. In the long term the GCL
bundle should assume the status of "just another ansi common
lisp". Axiom used to run on about a dozen common lisps so it
is nearly ported except for ansi changes

Noweb was chosen as an initial literate programming tool and
axiom was completely rewritten to make every source file (almost)
into a trivial case of a literate file. There has been some
controvery over what the long term format of Axiom will be,
spread among things like ALLPROSE, straight latex, noweb, 
a lisp-based noweb, etc. All of these are "tactical" discussions
rather than long term "strategic" discussions. 

Part of the difficulty in our discussions is that we are often
arguing from different starting points. I tend to start from
the philosophy and work "top down" and insist that the ideas
should shape the tools, Some others tend to start with the tool 
and work "bottom up", insisting that the tools should shape the
ideas. The results lie somewhere in between. Running code tends
to determine the actual result.


Tim