MathTypeResolution.mesa
Copyright © 1989 by Xerox Corporation. All rights reserved.
Arnon, August 28, 1989 1:42:36 pm PDT
DIRECTORY
SafeStorage,
IO,
Atom,
Rope,
Basics,
MathObjects;
MathTypeResolution:
CEDAR DEFINITIONS
Provides a type resolution algorithm.
Types of type resolution needed:
need to distinguish resolution of Elements from resolution of Structures
Need ability to find LUB type of multiple types, as a possible step in method lookup, i.e. if you can't find method in arg domains, try to resolve them to a new domain and look for it there.
Do we assume that all type resolution activities are done wrt, i.e in the presence of, some Environment? This would permit runtime control of type resolution algorithms, so that e.g. local or client-specific preferences could be applied.
Type resolution problems are of two types (we assume args and results are Elements, not Structures):
"Bound": we are given a particular Domain or View S, and a particular Element Object O, and we want to know if O can be converted (recast) to be an Element of S.
"Free": we are given a methodKey $foo, a list A of actual arg Element Objects, possibly an initial Domain, View, or Category, and we seek a Structure S which has a Method $foo, such that we can succeed at the "Bound" problem of converting the components of A to match foo$[S]'s runtimeType. Of course we hope that we can succeed using our initial given candidate for S, or a Structure to which some element of A belongs.
Capabilities are based on:
(1) the currently instantiated Domains, Views, Categories (with their attendant collections of Methods),
(2) the current system (global) Domain and Category lattices,
(3) currently known Packages,
(4) other means of Method lookup,
(5) possibly other sources of rules and heuristics.
Categories can enter type resolution, via (temporary) instantiation as part of Method Lookup, e.g. if we have an arg Object in a certain Domain D, and a methodKey $foo, we may first look for $foo in D and D's superDomains. If we do not so far find it, however, we now successively instantiate Views of D as an element of the various Categories which are pointed to by links from D into the Category lattice, and either in each such Category or some superCategory of it, we look for a method $foo.
Categories also enter into type conversion activities (which are completely guided by the current Domain and Category lattices), e.g. if a component of a method's runtimeType is a Category, then we will try to see if the actual parameter is an Element of a Domain or View which can be viewed as an element of that Category.
A special case of type resolution is "type inference", i.e. the attempt to have the system determine alternative (usually narrower) types for an Object.
The most common case of this is starting with an Object of type Expr. We begin with the obvious ability of MathExprs to associate types with the atomic "leaves" of the Expr. From this point on, we are doing type resolution as above.
A desired consistency principle in the system: For any object O,
O = TypeResolve[O.class.EltToExpr[O] ]
Types From Referenced Interfaces
ROPE: TYPE = Rope.ROPE;
STREAM: TYPE = IO.STREAM;
Object: TYPE = MathObjects.Object;
MethodDictionary: TYPE = MathObjects.MethodDictionary;
END.