<<>> <> <> <> <<>> DIRECTORY SafeStorage, IO, Atom, Rope, Basics, MathObjects; MathStructures: CEDAR DEFINITIONS = BEGIN <> ROPE: TYPE = Rope.ROPE; STREAM: TYPE = IO.STREAM; Object: TYPE = MathObjects.Object; MethodDictionary: TYPE = MathObjects.MethodDictionary; <> <> <<>> Category: TYPE = Object; Domain: TYPE = Object; View: TYPE = Object; Structure: TYPE = Object; Element: TYPE = Object; CategoryData: TYPE = REF StructureDataRep; DomainData: TYPE = REF StructureDataRep; ViewData: TYPE = REF StructureDataRep; StructureDataRep: TYPE; -- internal concrete rep; we expect and intend it to be the same for Domains, Views, and Categories <<>> <> <<>> <> <> Domains: Object; -- SystemObject; .class of any Domain DomainsData: TYPE ~ REF DomainsDataRep; DomainsDataRep: TYPE; -- includes the system (global) lattice of currently instantiated Domains; should be similar in spirit to a RefTab, except needs to be a Graph. Should be an immutable data structure, like ROPE, so that Domains can be instantiated within a local environment (e.g. a particular invocation of type resolution) and temporarily inserted in the global lattice, then easily deleted later. Categories: Object; -- SystemObject; .class of any Category CategoriesData: TYPE ~ REF CategoriesDataRep; CategoriesDataRep: TYPE; -- includes the system (global) lattice of currently instantiated Categories; needs to be a Graph a la DomainsDataRep. May or may not need to be immutable; unlike Domains, Categories will probably not be "temporarily" instantiated during type resolution, or any other time, and so it can be argued that the system should never forget a Category, once instantiated. Views: Object; -- SystemObject; .class of any View ViewsData: TYPE ~ REF ViewsDataRep; ViewsDataRep: TYPE; -- probably a RefTab of current Views; any lattice activity done either in the Domain or Category lattices. <> <<>> <<(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.