<<>> <> <> <> <<>> DIRECTORY SafeStorage, IO, Atom, Rope, Basics, MathStructures; MathStructuresImpl: CEDAR PROGRAM IMPORTS Rope EXPORTS MathStructures = BEGIN <> ROPE: TYPE = Rope.ROPE; STREAM: TYPE = IO.STREAM; Object: TYPE = MathObjects.Object; MethodDictionary: TYPE = MathObjects.MethodDictionary; <> <> <<>> StructureRep: TYPE = RECORD [ methods: MethodDictionary, -- methods of Category, Domain, View uniformly accessible data: REF _ NIL -- optional structure-specific data, e.g. a View should save its "underlying" Domain, Domains and Categories may have "properties", e.g. we may attach axioms to a Category. ]; Structure: TYPE ~ REF StructureRep; -- inside impl module, use rep <> <<>> < Category via the .class field. This is an instance of the "isAnElementOf" relation that in general we want an Object's .class field to express. In this case it may be of use for inheritance, in that Domains can "inherit" methods from a Category they belong to. However, we view it as merely a particular favored "basic" inheritance relation. In general, (multiple) inheritance is supported via the global Domain and Category lattices, that record all "isASubsetOf" relations among Domains and Categories, respectively. There is a certain consistency assumed between these lattices and the capabilities of the Domains and Categories involved in them. If we are trying to recast (an element of) Domain or Category S as (an element of) S', and if there is path from S to S' in the global lattice, then we assume that by (e.g. depth-first or breadth-first) search of the Widen or Narrow (depending on the direction of the path) edges rooted at S', we will find a "path" of procs which can be composed to actually do the recasting. Thus in general, the "transitive closure" of the Widen or Narrow "edges" rooted at a Structure S comprise a subgraph of one of the global lattices. The possible partiality of this subgraph is the major reason for the use of the global lattices: they give us a single place to express the full multiplicity of relationships among the Structures that are their nodes.>> <> <<>> <> <<>> <> <<>> <> <<1) create a node for itself in the Domain lattice>> <<2) identify (Narrow and Widen) edges in the Domain lattice of which its a vertex, and provide a proc for each such edge. There should be a precedence ordering among the Narrow edges, and among the Widen edges, to guide searches.>> <<3) provide at least one link (edge) from itself as a node in the Domain lattice, to a node of the Category lattice, together with a ViewAs proc for each such edge. Its .class field is one such link (except does not provide the ViewAs proc per se). Again, there should be a precedence ordering among these edges.>> <<>> <> <<1) create a node for itself in the Category lattice>> <<2) identify (Widen) edges in the Category lattice of which its a vertex, and provide a proc for each such edge. (Narrow procs seem impossible for Categories; e.g. for Ring -> ID, how do you give a proc that determines whether a given Ring has zero divisors?). There should be an ordering among these Widen edges.>> <<>> <> <<>> <> <<>> << >> END.