On Thu, Apr 2, 2009 at 4:27 PM, Ralf Hemmecke wrote:
>
>> | Note: This code is currently the same in both FriCAS and OpenAxiom.
>>
>> OpenAxiom issues this warning:
>>
>> Warnings:
>> [1] OpenAxiom suggests removing assignment to Rep
>
> Very nice.
>
>> | Since BinarySearchTree is a particular class of BinaryTree for
>> | consistency in BinarySearchTree I would expect to see:
>> |
>> | Implementation == BinaryTree(S) add
>> | Rep == List Tree S
>
>> As I said, I would not. I would not expect any definition of Rep at
>> all. The domain extension says BinaryTree(S) is the Rep of
>> BinarySearchTree(S).
>
> In fact, in add-inherited domains
>
> D: C == A add
> Rep == X
> ...
>
> one should not even be allowed to ever write anything else for X than
> just A. I think Open-Axiom is right to remove the necessity of the
> (redundant line "Rep == A").
>
> And why would one want that in Rep==X, X must be the same as A? Because
> suppose that A is defined like
>
> A: C2 == add
> Rep == X
> ...
>
> and for some reason you decide (as a maintainer for A) that it would be
> better to change your internal (not exported) representation from X to Y
> in an incompatible way (for example, Y=List(X)), then recompilation will
> break at compiling D, since then A and X have different underlying
> bit-layout.
>
I have been thinking about this for a while and I find that I am not
(yet) convinced by the arguments of Ralf and Gaby. I appreciate the
desire to avoid "leakage" of internal implementation details into code
that depends on external packages and domains, but it seems to me that
the concept of representation (as implemented by Rep, rep and per)
does in fact explicitly allow this in a fairly controlled manner - and
I think that the current panAxiom library seems to take good advantage
of that.
I think this treatment of Rep in SPAD makes it different than most
(all?) other programming languages. If we decide to tie Rep directly
to add in the manner described by Gaby and Ralf, and as currently
implemented in OpenAxiom, and if that became the only way to introduce
Rep, then SPAD would seem to become a language not so different than
most other object-oriented languages, e.g. Python, that depend class
inheritance (so called: sub-classing) as the only built-in mechanism
for implementing representation.
It is interesting perhaps to compare Sage which does implement some
additional notions related to representation by adding the "parent"
structure on top of Python.
Take a look at the following add-chains:
xlpoly.spad.pamphlet:
LiePolynomial ==
FreeModule1 add
TERM ==> Record(k: LWORD, c: R
Rep := List TERM
LieExponentials ==
XPBWPolynomial add
Rep := XPBWPolynomial
XPBWPolynomial ==
FreeModule1 add
TERM ==> Record(k:BASIS, c:R)
LTERMS ==> List(TERM)
Rep:= LTERMS
xpoly.spad.pamphlet:
XDistributedPolynomial ==
XPolynomialRing add
TERM ==> Record(k:WORD, c:R)
Rep := List TERM
XPolynomialRing ==
FreeModule1 add
TERM ==> Record(k: E, c: R)
Rep:= List TERM
FreeModule1 ==
FreeModule add
TERM ==> Record(k:S,c:R)
Rep := List TERM
poly.spad.pamphlet
UnivariatePolynomial ==
SparseUnivariatePolynomial add
Rep:=SparseUnivariatePolynomial(R)
SparseUnivariatePolynomial ==
PolynomialRing add
Term := Record(k:NonNegativeInteger,c:R)
Rep := List Term
PolynomialRing ==
FreeModule add
Term:= Record(k:E,c:R)
Rep:= List Term
FreeModule ==
IndexedDirectProductAbelianGroup add
Term:= Record(k:S,c:R)
Rep:= List Term
indexedp.spad.pamphlet:
IndexedDirectProductAbelianGroup ==
IndexedDirectProductAbelianMonoid add
Term:= Record(k:S,c:A)
Rep:= List Term
IndexedDirectProductOrderedAbelianMonoid ==
IndexedDirectProductAbelianMonoid add
Term:= Record(k:S,c:A)
Rep:= List Term
IndexedDirectProductAbelianMonoid ==
IndexedDirectProductObject add
Term:= Record(k:S,c:A)
Rep:= List Term
IndexedDirectProductObject ==
add
Rep:= List Term
There are only two cases in the chains above where the current add
domain is chosen as Rep.
Having looked at this code in more detail I find I have doubts about
Gaby's claim: "those domains can be profitably rewritten without
having to know how FreeModule is implemented". It seems likely to me
that any attempt to do so could result in a significant loss of
performance in a very critical and central part of the panAxiom
library.
Of course we can retain the current notation in panAxiom that allows
Rep to be explicitly specified, separate from 'add', but if we want a
less idiosyncratic approach were Rep is tied to add-inheritance it
seems to me we need to seriously consider the option I mentioned
earlier of making the (default?) Rep X in
A: C2 == add
Rep == X
equal to the Rep of C2 and not C2 itself. I think that before choosing
either option for the treatment of add-inheritance and Rep, it would
be a worthwhile project to attempt to convert the above add-chain to
the 'Rep==C2' style of representation and to evaluate the impact that
that might have on performance.
Regards,
Bill Page.
------------------------------------------------------------------------------
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
