Bill Page <bill.p...@newsynthesis.org> writes: [...]
| Notice that the "add" keyword introduces a domain from which some code | and it's associated **representation** while be inherited, so really | there is no need to specify Rep in the following case: | | Foo(...): with | ... | == OldDomain add | ... rep ... per ... This construct is already supported by OpenAxiom, with the uses of 'rep' and 'per' as usual. The difference with what you want, I think, is that this is the construct for extending OldDomain into Foo. Consequently, OldDomain must export a subset of the signatures exported by Foo. At the moment, you only get a warning if you fail to meet that requirement, but that may change in the near future. | The Rep in Foo must be the same as Rep in OldDomain. The semantics of the above construct in OpenAxiom is that OldDomain domain becomes the Rep of Foo. Consequently, both Foo and OldDomain are conformant to each other (this is a theorem), e.g. their VM-level representations are the same. | On the other hand, if there is no OldDomain then it is necessary to | specify the domain that will represent this new domain. We could do it | like this: | | Foo(...): with | ... | == Rep(SomeDomain) add | ... rep ... per ... In general, I like the abstract datatype approach taken by both OpenAxiom and Aldor. I would like to see critical use cases and sound programming styles or scalable idioms that are eased by exposing implementation details by exporting Rep. | The general semantics of Rep(SomeDomain) would be exactly the same as | | Rep == SomeDomain | | in Aldor and OpenAxiom. -- Gaby ------------------------------------------------------------------------------ _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
