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

[Martin Rubey]

William Sit <address@hidden> writes:

> In case of multiple inheritance, it is the responsibility of the user to 
> choose,
> not asking the compiler to choose for you (that would be equivalent to asking
> the Interpreter to coerce and then complain about the result or resulting 
> type).
> It would be trivial to override (and choose) by something like:
> 
>    default(#: %)->Integer == #$(MyFancyCat T)
> 
> or 
> 
>    default(#:% ->Integer == #$FixedArrayType(n,T)

> 
> The compiler should not choose this and should flag it as a user error.

William, I agree! (in both points)

> By the way, I don't follow his example at bottom of p. 127: If \phi is a 
> functor
> (he said homomorphism, but that is wrong, because a list and a set are from
> different categories), he wants the equation to hold:
> 
>     \phi(#([1,1]) = #(\phi([1,1]))
> 
> The right hand side makes sense, with answer 1, but the left hand side does 
> not,
> since #([1,1]) = 2 is a number, not a list. He claimed \phi(2) = 2.
> In addition, there is no requirement that a functor commutes with operations. 
> A
> functor should, in addition to taking objects (lists) to objects (sets), also
> has to take a morphism *between* source objects (lists) to another morphism
> *between* the image objects (sets). The map '#' is not a morphism in the
> category of Lists, nor of Sets. If one must, then '#' is a functor from the
> category of Lists (and also for Sets) to the category whose objects are
> non-negative integers. But the composition of functors \phi \circ # does not
> make sense.  What Doye has in mind is the following diagram:
> 
>                  #
>           Lists --> NNI
>             |        |
>        \phi |        |  id
>             v   #    v
>           Sets  --> NNI
> 
> But there is no reason to expect this to be a commutative diagram of functors.
> So I think his example illustrates nothing.

Thank you for pointing out this. I had the same feeling, but I wasn't sure
enough about it. Now it's settled.

> I think you just demonstrated the rigidity of computer languages. I believe
> allowing "user renaming" of functions sets up another level of abstraction
> that will only cause more confusion and will not solve the problem of
> multiple inheritance (I may change my mind after reading Doye). The designers
> of Axiom made a good compromise, even though it does not reflect the true
> mathematics algebraic hierarchy. One possible improvement (but far from a
> total solution) is to include inheritance via isomorphisms, but even that is
> a lot of work.

Do you mean that passing operations to the categories would be a feasible
approach? I.e., being allowed to say something like

Monoid(m:(%,%)->%): Category == with
       square: % -> %

     add
       square a == m(a,a)

Of course, one would have to rethink this several times, the suggested notation
here is clearly not yet perfect. One might object that this notation violates
the possibility of creating anonymous categories, but I suspect that this
wouldn't make sense anyway.

Martin