DIRECTORYRope,MathObjects,MathStructures,MathExprs;MathExprsImpl: CEDAR PROGRAMIMPORTS RopeEXPORTS MathExprs = BEGINROPE: TYPE = Rope.ROPE;STREAM: TYPE = IO.STREAM;Object: TYPE = MathObjects.Object;ExprDataRep: TYPE ~RECORD [SELECT type:* FROMatomic => [op: ATOM,  -- type of entity, e.g. $integer, $real, $symbol (our notion of a symbol is essentially that of an "identifier", i.e. a legal "name" which is capable of having an associated value), $string, $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.],composite => [op: ATOM,  -- operatorargs: LIST OF Object _ NIL -- operands]ENDCASE];ExprData: TYPE ~ REF ExprDataRep;  -- inside impl module, use repEND.   V  MathExprsImpl.mesaLast Edited by Arnon: September 6, 1989 10:51:10 am PDTGround Domain corresponding to General ExpressionsExternal rep is "Exprs"Types From Other InterfacesElement Representation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 args.  And of course, by invoking eltEval$Exprs, we can always abrogate our relaxedness and try to limit the Object to a narrower domain.  ‌ت¦  •NewlineDelimiter™ Jڑœ™Jڑœ7™7Jک Jڑœ2™2J™J™ ڑدk	ک	IcodeڑœکKڑœکKڑœکKڑœ
ک
—head2ڑœ‌œ‌کJڑ‌œکJڑ‌œ
کJڑœک—Kڑœ‌کheadڑدn™Kڑ‌œ‌œ‌œکKڑ‌œ‌œ‌œ‌œکKڑœ‌œک"—ڑ‍™ڑœ‌œکڑ‌œکڑ‌œ‌ککKڑœ‌œدcؤکدKڑœ‌œںصکâKک—کKڑœ‌œںکKڑœ‌œ‌œ
‌œںک&Kک—Kڑ‌ک—KکKک ——ڑœ
‌œ‌œںکAKک Kڑœْ™ْKڑœˆ™ˆ——Jک Jڑ‌œکJک — …—    ى  è  