Edit detail for Axiom Algebra revision 1 of 5

changed:
-
<a href="Lattice.pamphlet">Lattice.pamphlet</a>

Adding new algebra

  This is a complex process by its very nature. Developers and Maintainers
who undertake the process need to understand quite a lot of detail. The
ultimate steps to add algebra are tedious but simple. Note that only
algebra code that gets shipped with the system needs to undergo this
process. User code can be compiled once the distributed algebra exists
and does not need either this Makefile or this installation process.

Since understanding is the key to making correct changes to this file
I'll work on explaining the details of why things need to exist. 

The first idea that you need to understand is the overall process
of adding algebra code. Lets assume that you have a brand new spad
file, called *foo.spad* containing a simple domain *BAR*. The
steps in the process of adding this file are:

0  Find out where the algebra code lives in the lattice.

   You do this by 

1 starting a new interpsys session

2 collecting all the names of the algebra files BAR requires

3 determining which layer each of the required files resides

4 determine the highest layer (e.g. 14) that contains the required files

5 insert the documentation into the next layer (e.g. 15)

6 insert the *BAR* file into the layer's file list

7 create a new subsection for the *foo.spad* file

8 add a stanza to extract *foo.spad* from *foo*

9 add a stanza to extract *foo.dvi* from *foo*

10 add a stanza to compile *foo.spad* to get *BAR.lsp*

11 add a stanza to compile *BAR.lsp* to get *BAR*

12 add a stanza to copy *BAR* to the final algebra directory 

13 add the 5 chunk names into the default Makefile section

Rebuilding the algebra from scratch

  Compile order is important. Here we try to define the ordered lattice
of spad file dependencies. However this is, in reality, a graph rather
than a lattice. In order to break cycles in this graph we explicitly
cache a few of the intermediate generated lisp code for certain files.
These are marked throughout (both here and in the various pamphlet
files) with the word **BOOTSTRAP**.

If we take a cycle such as **RING** we discover that in order to
compile the spad code we must load the compiled definition of {bf RING}.
In this case we must compile the cached lisp code before we try to 
compile the spad file.

The cycle for **SETCAT** is longer consisting of: **SETCAT** needs
**SINT** needs **UFD** needs **GCDDOM** needs **COMRING** needs
**RING** needs **RNG** needs **ABELGRP** needs **CABMON** needs
**ABELMON** needs **ABELSG** needs **SETCAT**.

It is highly recommended that you try to become a developer of Axiom
and read the archived mailing lists before you decide to change a
cached file. In the fullness of time we will rewrite the whole algebra
structure into a proper lattice if possible. Alternatively we'll
reimplement the compiler to handle graphs. Or deeply adopt the
extensible domains. Whatever we do will be much discussed (and cause
much disgust) around the campfire. If you come up with a brilliant
plan that gets adopted we'll even inscribe your name on a log and add
it to the fire.

In the code that follows we find the categories, packages and domains
that compile with no dependencies and call this set ``layer 0''. Next
we find the categories, packages and domains that will compile using
only ``layer 0'' code and call this ``layer 1''. We walk up the
lattice in this fashion adding layers. Note that at layer 3 this
process runs into cycles and we create the ``layer 3 bootstrap''
stanzas before continuing upward.

I used to have code that would automatically generate this lattice but
it got lost in the move from IBM to NAG. The current information was
hand generated during the coding of this Makefile.  Except for the
bootstrap files most of the stanzas have the dependency graph encoded
in the precondition lists for each makefile stanza. Thus we can see
that building the package **ANY1** requires the category **TYPE**::

  ANY1.NRLIB: TYPE ANY1.spad

This information also exists in the comments before each layer.
Ordinary users of Axiom won't need to know this. However developers
of the standard system should strive to keep this information up to
date and correct. The spad compiler will tell you this information
as part of the compile.

Once we reach the point in the lattice where all of the individual
categories, domains and packages in each spad file have been compiled
we can start building the system directly from the whole spad code
files rather than the individual domains.

The Algebra Lattice Layers

- [Layer 0]

- [Layer 1]

- [Layer 2]

- [Layer 3]

- [Layer 4]

- [Layer 5]

- [Layer 6]

- [Layer 7]

- [Layer 8]

- [Layer 9]

- [Layer 10]

- [Layer 11]

- [Layer 12]

- [Layer 13]

- [Layer 14]

- [Layer 15]

- [Layer 16]

- [Layer 17]

- [Layer 18]

- [Layer 19]

- [Layer 20]

- [Layer 21]



From unknown Sat Oct 23 04:41:51 -0500 2004
From: 
Date: Sat, 23 Oct 2004 04:41:51 -0500
Subject: Layers 22 & 23 missing
Message-ID: <20041023044151-0500@page.axiom-developer.org>


Following the discussion on summing (see http://lists.nongnu.org/archive/html/axiom-developer/2004-10/msg00098.html) I wondered how one might get an understanding of COMBF and all the other domains/ categories it depends on. As an earlier email had recommended to use MathAction with TouchGraph to browse through the documentation, I tried that, but came to a wall as COMBF seems to sit in layer 22 and documentation only goes up to layer 21.

  ANY1.NRLIB: TYPE ANY1.spad