Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> Martin Rubey <[EMAIL PROTECTED]> writes:
>
> | Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> |
> | > | Gaby, after some experiments, I could not find an example where "A add
> B", A
> | > | and B sharing representation, exports an operation from A instead of
> from B,
> | > | when the signature is present in both.
> | >
> | > That is basically what my oiriginal example was about --
> |
> | Sorry, I don't understand. In the example below, the representations
> differ -
> | IndexedDirectProductAbelianGroup(R,S) is (I'd say) different from List
> | Pair(S,R).
>
> No, they have the same layout -- would you mind having a look at
> IndexedDirectProductAbelianGroup?
I did. Only, I was thinking of IndexedDirectProductAbelianGroup(R,S) being
different from List Pair(S,R), because I did *not* identify
IndexedDirectProductAbelianGroup(R,S) with Rep in
Term:= Record(k:S,c:A)
Rep:= List Term
> | I wonder whether this strange behaviour also occurs when the representations
> | are the same.
>
> I think I said yes in my previous message. Which point point isn't clear?
Maybe I should have said, "when the representations are identical".
But I admit that I didn't notice at first that the representations are, in some
sense, "compatible", and that this could be allowed. I'm not sure whether this
is good or bad.
I find it interesting (I didn't know) that it seems to be allowed in Aldor, and
the behaviour is, that in
A add B
operations defined in B are preferred over operations in A. (page 228 and 229
of the Aldor User Guide). But I did not check all the details. What would
interest me most: which "*" is taken in line 50 of the program there?
OK, I checked. It takes the one from ModularIntegerNumberRep
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
open-axiom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
