Re: [Axiom-mail] AXIOM documentation
Welcome Alan,
The first thing I'd like to support is Bill's suggestion that you should
look at Aldor in order to understand the programming language. Axiom's
SPAD (its compiler language) is a little different, but if you encounter
differences and don't understand them, then it is probably better to ask
again at the list (and maybe then write down some notes so that these
differences become explicit --- best to do on a page at the MathAction
(the Axiom wiki) http://wiki.axiom-developer.org/FrontPage . Replace
FrontPage by some reasonable term and create that page. If you first
would like to experiment with the wiki then start you term with Sandbox...
I am trying to understand the documentation. Below are some notes
based on Chapter 5 of the book. The system seems to be based on a
directed graph whose nodes are Axiom objects and whose edges are of
two sorts which could be called
member
a is a member of b if b is a domain (or subdomain?) and a's type is b
refines
c refines d if all members of c are members of d and in addition
all operations of c are operations of d.
Is this right?
[snip]
In the book, Figure 1 shows a bit of this graph for the refines
relation and for some basic domains of algebra. Could someone please
draw a similar graph with nodes including
Type
Category
Domain
Any
SetCategory
Symbol
Variable ?
These are the obscurest objects. Someone has tried to explain them
in bookvol1 Chapter 5, but it is hard. See the notes below.
As you will find in the Aldor User Guide everything has a type.
You can see at Aldor as a language that has 3 levels of things (well, I
wanted to say object, but that gets easily confused with that concept
in OOP.
(Before anybody wants to complain that I am not totally correct, I'd
like to say that I did this by intention in order to simplify the first
steps for a new user/developer.)
Example (I don't refer to Axiom but rather to the library LibAldor so
the names might not be know to Axiom):
1st level: 42 (is of type Integer)
2nd level: Integer (is of type IntegerType)
3rd level: IntegerType (is of type Category)
The first level I'd like to call simple objects (but they are
*definitely not* objects in the OO sense).
The things at the second level are called domains. (A package is a
special domain.)
The things at the third level are called categories.
The name Category is a special built-in name that denotes the type of
a category (i.e. the type of things at third level).
The things at second level are formed using the add {...} construction.
The things at third level are formed using the with {...} construction.
The things at second and third level are called types.
The identifier Type is builtin. It is the type of any type, (Something
like the set of all sets---don't think about Russel's paradox here.)
Think of the things at third level as something comparable to JAVA
interfaces. (That is not completely exact, but quite near to my taste.)
There are different ways of inheritance.
Second level: single inheritance.
MyDom: with {
0: %;
foo: % - %;
} == Integer add {
foo(x: %): % == x;
}
The domain MyDom exports exactly 2 things, the constant 0 and a
function foo. As you can see, I have not given a definition for the
implementation of 0. That implementation is inherited from the domain
Integer.
Third level. Since that is not connected to implementations, but rather
only signatures of functions, multiple inheritance is allowed.
So if you have
define CatA: with {foo: %-%, bar: %-()}
define CatB: with {foo: (%, %)-%; bar: %-()}
define CatC: Join(CatA, CatB} with {baz: () - %}
then the last definition is (nearly) equivalent to
define CatD: with {
foo: %-%;
foo: (%,%)-%;
bar: %-();
baz: () - %
}
It simply forms the (non-disjoint) union of all the signatures.
I said nearly because in the definition
define CatC: Join(CatA, CatB} with {baz: () - %}
CatC remembers that it inherits from CatA and CatB while in the second
definition, there is no relation to CatA and CatB.
So if you define domains
DomC: CatC == add {...}
DomD: CatD == add {...}
and later use constructs like
if DomC has CatA then ...
if DomD has CatA then ...
then DomC has CatA is true while DomD has CatA is false.
Does this help a bit?
I have not yet worked out how to refine a domain. There is a hint on
page 14 of the book: Complex(R) defines its exports with
Ring with ... if R has Field then Field ...
Complex is a domain constructor, i.e. a function that returns a domain
as a result.
Yes, and it should be emphasized that things of first, second, and third
level are all first class citizens, i.e. each of them can appear as an
argument to a function. For example Complex is such a function. It
takes a domain (something of level 2) as argument and returns a domain.
In Aldor, you could also write something like
#include algebra
#include aldorio
Re: [Axiom-mail] AXIOM documentation
On 6/20/07, Alan Hutchinson wrote: ... I am trying to understand the documentation. Below are some notes based on Chapter 5 of the book. The system seems to be based on a directed graph whose nodes are Axiom objects and whose edges are of two sorts which could be called member a is a member of b if b is a domain (or subdomain?) and a's type is b refines c refines d if all members of c are members of d and in addition all operations of c are operations of d. Is this right? That is a very good start. I am glad that you are taking the time to understand Axiom at this level. Many people start with Axiom thinking that it is just another computer algebra system (like, Maxima, Maple, Mathematica, etc.) but that can lead to a lot of initial confusion. I have come to believe that it is probably better to emphasis Axiom's type and object system right from the beginning (during the first few experimental computations). I think itis essential to get a basic understanding of these concepts if one is going to progress beyond the first few pages of any tutorial. I personally find most of the Axiom book a little confused (or at least written in a confusing manner) when it discusses types. If you have a computer sciense background or a high tolerance for a terse but accurate description of the Axiom language, then I think the Aldor User's Guide: http://www.aldor.org/mediawiki/index.php/Aldor_Documentation is a great place to start. In so doing you are essentially starting at the end (or a least the latter phase) of the original Axiom development while it was still a research project at IBM. One of the design ojbectives of Aldor was to bring some order and conclusion to the system and programming language design that was a result of the earlier research and experimentation. So even though Aldor is not (at least not yet :) a part of the Axiom open source release and though you may not be planning to program in Aldor, I think it is a good place to start because it distills many of the concepts implemented in Axiom to their essense and presents them in a more rigorous manner than in Axiom itself. In particular you should pay particular attention to Chapters 7: Types and 13: Language-defined types http://aldor.org/docs/HTML/chap7.html http://aldor.org/docs/HTML/chap13.html Pay particularly close attention to the concept of type satisfaction. Once you understand something about types, I think it much easier to appreciate the kind of things that the Axiom interpreter tries to do to relieve you of the burden of always having to be specific about types and the relationships between objects. Probably not quite, since c may have operations with the same names as operations in d but different interpretations, in which case c would not refine d. Actually that is also true. Some thing that is important to remember is that domains members of named categories by *assertion* - not just because they implement a certain set of operations with common signatures. See: A First Course on Aldor with libaldor http://www-sop.inria.fr/cafe/Manuel.Bronstein/libaldor/tutorial.pdf It is also interesting to read: Domains of data and domains of terms in AXIOM by BROWN, R. DRECKMANN, W in http://www.informatics.bangor.ac.uk/public/math/research/preprints/95/algtop95.html or http://portal.axiom-developer.org/refs/articles/brown-free-c-g.pdf/file_view This is at least in part what gives the concept of category in Axiom it's expressive power since the name that we give to categories often stand of mathematical axioms. In the book, Figure 1 shows a bit of this graph for the refines relation and for some basic domains of algebra. Could someone please draw a similar graph with nodes including Type Category Domain Any SetCategory Symbol Variable ? These are the obscurest objects. Someone has tried to explain them in bookvol1 Chapter 5, but it is hard. See the notes below. As the Aldor documentation points out, the relationship between categories is different from the relationship between domains and categories and form the relationship of objects to domains. Both Categories and Domains are Types (Axiom has a two-level type system.). Things like Monoid, Ring, Field, and IntegralDomain are categories, while Any, SetCategory, Symbol and Variable are all domains. If you have some experience with object-oriented programming than it is useful to realize that domains are like classes. Categories are a little different and more abstract. They help to express generic programming in Axiom - that is a generalized specification for algorithms that apply over a very wide range of data types. The next issue is how to extend this graph. It seems easy to add a new node X with member edges: if X is to be a domain of class C then use C's natural constructor: X := C(...) if X is any other type of object of some type T then declare X : T := ... I am afraid you might be defining new
