MathExprsImpl.mesa
Last Edited by Arnon: September 6, 1989 10:51:10 am PDT
Ground Domain corresponding to General Expressions
External rep is "Exprs"
DIRECTORY
Rope,
MathObjects,
MathStructures;
MathExprsImpl: CEDAR PROGRAM
IMPORTS Rope
EXPORTS MathExprs
= BEGIN
Types From Other Interfaces
ROPE: TYPE = Rope.ROPE;
STREAM: TYPE = IO.STREAM;
Object: TYPE = MathObjects.Object;
Element Representation
ExprDataRep: TYPE ~
RECORD [
SELECT type:* FROM
atom => [
method: ATOM, -- type of entity, e.g. $integer, $real, $symbol, $char
value: ROPE -- atomic value, e.g. integer as rope. Any legal name (e.g. Greek letter, subscripted variable, etc.) should be an atomic Expr of type $symbol (or we can have types $greekSymbol, $decoratedSymbol, etc., or $name ...). Better to have just one type $symbol, and plan to parse it to determine possible subcomponents, and so the right display.
],
compound => [
method: ATOM, -- operator
subObjects: LIST OF Object ← NIL -- operands
]
ENDCASE
];
ExprData: TYPE ~ REF ExprDataRep; -- inside impl module, use rep
Given our assumption of one or more EltToExpr procs in all domains (see below), allowing arbitrary Objects as subExprs, rather than limiting to Exprs, is essentially just being flexible with regard to the amount of local type inference that has been done on subExprs of an Expr. E.g. if we required subExprs to be Exprs, a user could of course at any time select a subExpr and EltEval (type narrow) it, and indeed he may be imagining in his mind that this has in fact been done for a subExpr of interest. And, of course, application of a EltToExpr proc can always undo the casting of any subObject as an element of a (narrower) domain. Hence it is appropriate to have a data representation that supports easily going back and forth between the two viewpoints.
Since we can have Expr Objects which are just an "outermost method" applied to Objects belonging to narrower domains, plus the assertion of membership of the whole in the Exprs domain, we make think of Exprs objecthood as a kind of "packaging", or "brush stroke", of collections of (other) Objects, that is tantamount to a declaration that we want to be relaxed, or insensitive, about the type of the total package. And, with EltToExpr procs, we have always the possibility of propagating this relaxedness to subObjects. And of course, by invoking eltEval$Exprs, we can always abrogate our relaxedness and try to limit the Object to a narrower domain.
END.