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.