RE: [Axiom-developer] Curiosities with Axiom mathematical structures

[Page, Bill]

On Monday, March 13, 2006 2:39 PM William Sit wrote:
> ... 
> If we are allowed to change the notation for the monoid 
> structure so that a set can have multiple monoidal
> structures and we can inquire about it, then some
> code like:
> 
>    If X has Monoid("*") then ...
> 
> would have no definite meaning since you will NOT know
> the operator in X that makes it a monoid.

??? I thought that was precisely what Martin wants this
to mean. Obviously '*' is the operator in question. More
precisely one might write:

    If X has Monoid(*$X) then ...

> Even if you happen to guess the correct **notation**, you
> still would not know what the **definition** of the operator 
> is without looking at the code for "*", manually, of X.

I don't think any "guessing" is involved.

> In other words, you have NO way to know when you write that
> code that the operation "*" that is matched (when 'X has
> Monoid("*")' returns 'true') that it is the operation you 
> have in mind in the code following 'then' since by your
> testing the predicate, you admit that you don't know what
> X is at run time.

??? I don't think what you wrote above makes sense. Obviously
the program does "know" what X is. It has presumably been
passed from some other part of the program or from the user
via the interpreter. But the point is we do not want to write
code that is specific to X but rather code that will work
provided that X has a monoid structure with the binary
function *$X.

> 
> The way this need to be handled is to use accepted conventions
> for different types of monoid operations (and of course, we
> can't have it all, but whatever we have in the system, it
> would be documented and uniquely named. So we can write
> code with no ambiguity. Examples would be AbelianMonoid
> (using "+"), CompositionMonoid (using \circ), MaxMonoid
> (using 'max'), etc.

No! This is exactly what Martin is trying to avoid.

> But really, there is really no need for such proliferation
> unless many descendents are anticipated.

I think Martin's point is not so much related to a specific
programming need, but rather to the desire to write code
that corresponds to common mathmatical usage.

> 
> If you want to avoid duplicating code, like 'square', we
> can define 'square(m:%->%, x:%)' for any X:Type in a
> package. (This example can be generalized clearly).
> 

In fact in Axiom with SPAD default implementations in
categories are implemented as a package with a special
name related to the name of the category.

Regards,
Bill Page.