Martin Baker <[email protected]> writes:
| > | However this would not be compatible with existing PropositionalFormula
| > | and it would not be closed. That is I would like:
| > | PropositionalFormula Product(A,B)
| > | PropositionalFormula Sum(A,B)
| > | PropositionalFormula Exponent(A,B)
| > | all to be treated as: PropositionalFormula SetCategory
| > | Can that be done in a way that is compatible with SPAD static typing.
| >
| > SetCategory is a category, not a domain, so is not appropriate argument
| > for PropositionalFormula. Categories cannot be constructor arguments --
| > all AXIOM flavours affected.
| >
| > In OpenAxiom, you use the domain Domain, so you would get something like
| >
| > PropositionalFormula Domain
| >
| > which is probably what you want.
|
| Gaby,
|
| The Domain domain has minimal documentation (about 2 lines of in-line
comments
| for each public function), I can't find anything about: why it was created?
| how its intended to be used? and so on. Most of the functions call Lisp code
| so there is not many clues there. I am guessing its part of the universal
| algebra stuff you mentioned before? Is this all intended to be part of a meta
| model of OpenAxiom? Will it allow introspection and dynamic code creation?
|
| Is there any further documentation about this? I get the impression that the
| universal algebra stuff is potentially very powerful but I am very reluctant
| to use something that is only available on one flavor of axiom, are other
| flavors of Axiom planning to implement this functionality?
|
| Have I missed any documentation about this?
|
| Martin
Martin --
At first, I was puzzled by your message. Then I realized that you were
using the word "documentation" when in fact you meant *tutorial*, which
is not the same thing. And in general, unfamiliarity with AXIOM
terminology may hinder communication.
What you call "in-line comments" are NOT comments in the traditional
sense of the term that you find in some other programming languages.
They are *descriptions*, e.g. documentation that the OpenAxiom compiler
keeps so that users can find them by browsing (e.g. HyperDoc) or other
utilities that manipulate OpenAxiom system databases.
Descriptions are texts starting with the double-plus sign "++".
In general, I document every piece of domain I implement. If you write
an algebra code and you do not provide a description for the constructor
or exported operations, the OpenAxiom compiler will yell at you.
Some people get by without documentation by writing \undocumented in the
description. I NEVER do that.
A comment is a text that starts with the double-dash sign "--". They
are ignored by the OpenAxiom compiler (i.e. equivalent to blank.) I do
not believe that is what you were referring to in your message, so it is
best to say what you mean so I can help you the best I can.
Hopefully, you appreciate now that there is a distinction between a
description and a comment, and one that is important.
A documentation is different from a tutorial. A documentation is a
reference manual. If you take the AXIOM book, then appendices B through
E constitute documentations of AXIOM categories, domains, packages and
operations. Chapters 1 through 14 constitute a tutorial. You will
surely note the difference in style. A tutorial is usually extensive in
background, and somehow informal. A good tutorial will usually repeat
the same information at least twice, and slightly differently. A good
way to introduce inconsistency opportunities in a documentation is to
repeat the same information twice. Rather, a documentation uses links
so that information is kept (hopefully) in sync.
The algebra is not the right place for a tutorial. I appreciate other
people have differing opinions. A tutorial should not be tangled with
fairly deep documentation and implementation consideration, in the same
way N. Bourbaki volumes make for a poor tutorial material for how to use
math or learn how to do math when you are just beginning.
Yes, OpenAxiom needs more tutorial materials.
Concerning the documentation of the domain Domain.
First of all, Domain is a fairly technical domain intended for
very advanced uses. By the time you are using Domain, you are already
supposed to know what a domain is. For an introduction to the `domain'
concept, see the tutorial part of the AXIOM book. For more advanced
coverage of the concept see Chapter 13. Familiarity with that chapter
is needed to understand what `Domain' is all about.
Because `Domain' is an abstraction of implementation details of the
system, some details are by necessity left out -- because they are
implementation details that have no business leaking out.
The domain `Domain' provides representation for all domain values.
That is, in some circumstances, a domain (e.g. a type and prescription
of value representation) is itself a value. Such is the case when you
instantiate a constructor with some arguments, e.g. in Polynomial
Integer, Integer is evaluated to a domain value that is passed to the
constructor 'Polynomial' to create a new domain value. Most users do
not care about these fine details. However, when you get to a point
where you want to manipulate domains as objects, I think the minimum is
that you read chapters 11 through 13 of the AXIOM book.
The operation 'constructor' does what its documentation says:
++ constructor(d) returns the domain constructor that is
++ instantiated to the domain object `d'.
Similarly, `reflect' does what its documentation says:
++ reify(d) returns the abstract syntax for the domain `x'.
Similarly, the operation `reflect' does what its documentation says:
++ reflect cc returns the domain object designated by the
++ ConstructorCall syntax `cc'. The constructor implied
++ by `cc' must be known to the system since it is instantiated.
Similarly, the operation `showSummary' does what its documentation says:
++ showSummary(d) prints out implementation detail information
++ of domain `d'.
-- Gaby
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
