Bill Page <bill.p...@newsynthesis.org> writes: | On Thu, Apr 2, 2009 at 2:19 PM, Gabriel Dos Reis <g...@cs.tamu.edu> wrote: | > Bill Page writes: | > | > | 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). | > | | Sorry, then this is my confusion.
confusion seems cleared then. | As I said, I expected that the Rep | of BinarySearchTree should be the same as the Rep of the domain from | which it inherits - *not* the domain itself. I think that is unnecessary leakage. Indeed, if I understand your description correctly, 'rep' would return a value of the Rep of old domain, this achieve the effective effect of exporting Rep -- because, you can now write functions to get access to that representation. That breaks abstraction. On the other hand, if BinaryTree(S) is the Rep, any change in the representation of BinaryTree(S)'s Rep will not leak out. This is one of the advantages of using abstract datatypes. Note that at the VM-level, the Rep will be the same -- by simple transitivity. | My (perhaps poor) understanding of add-inheritance | | NewDomain(): with | ... exports ... | == OldDomain add | ... body ... | | was that all functions and constants defined in the OldDomain | (regardless of whether they are exported or not) are visible to code | in the body of the new domain. Is that true or not? What do you mean by 'visible'? The semantics is that only functions exported by OldDomain are available. NewDomain does not have any special access to OlDomain's non-exported functions, no more than any other domain. | In the Axiom Book it says: | | 13.8 Add Domain | ... | The Implementation part of a definition can optionally specify an ⌠add- | domain■ to the left of an add (for QuadraticForm, defines SquareMatrix(n,K) | is the add-domain). The meaning of an add-domain is simply this: if the cap- | sule part of the Implementation does not supply a function for an operation, | Axiom goes to the add-domain to find the function. | --- | | Perhaps it is not so clear what "Axiom goes to the add-domain to find | the function" means. | | In clifford.spad.pamphlet I see: | | SM ==> SquareMatrix | ... | Impl ==> SM(n,K) add | Rep := SM(n,K) | | which obviously corresponds to your interpretation, Gaby. Yes. I must emphasize that the above is about exported function. Non-exported functiosn don't cross abstraction barriers (the capsule.) | There are numerous other examples of this in the library. | | But in 'xlpoly.spad.pamphlet' I see: | | LiePolynomial(VarSet:OrderedSet, R:CommutativeRing) : Public == Private where | ... | Private == FreeModule1(R, LWORD) add | import(TERM) | | --representation | Rep := List TERM | | and in 'xpoly.spad.pamphlet' we have: This is a breakage of the capsule abstraction barrier. One that I've always thought should be fixed. However, it is not one that is urgent because those constructs are so few in number. | | FreeModule1(R:Ring,S:OrderedSet): FMcat == FMdef where | ... | FMdef == FreeModule(R,S) add | -- representation | Rep := List TERM | | and in 'poly.spad.pamphlet': | | FreeModule(R:Ring,S:OrderedSet): | Join(BiModule(R,R),IndexedDirectProductCategory(R,S)) with | if R has CommutativeRing then Module(R) | == IndexedDirectProductAbelianGroup(R,S) add | --representations | Term:= Record(k:S,c:R) | Rep:= List Term | ... | | which looks more like what I expected to find. From my perspective, these are abstraction barrier breakage. I think those domains can be profitably rewritten without having to know how FreeModule is implemented. There is exactly one case where I'm undecided about what to do -- that is about a domain I introduced in OpenAxiom. But, I don't think the solution needs leakage of implementation details. -- Gaby ------------------------------------------------------------------------------ _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
