[e-lang] StaticScope's hasMetaStateExpr definition

[Kevin Reid]

On Jul 23, 2006, at 14:00, Mark S. Miller wrote:
> Kevin Reid wrote:
>> To me, there is not really any difference, except in the style of the
>> interface. E-on-CL uses macros to define CL classes, but it could
>> just as well be done with a single class with a 'node type' slot;
>> that is only an implementation choice.
>
> Perhaps this issue illustrates well the power of macros, and the  
> pain of doing
> without them. In E-on-Java or E-on-Squeak, this would require 65 class
> definitions, which at least seem much heavier than 65 BNF  
> productions and
> expansion rules. Similarly, in an E-on-E embedding this would  
> require 65
> object definitions.

E code can be generated and evaluated; this is equivalent to macros,  
especially if we can arrange for sufficient constant folding. But  
since E objects are fully dynamic (no static detectable type-of-this- 
object), there's no reason (other than some optimization) to define  
each node variety separately.

> OTOH, the "single class with a 'node type' slot" representation  
> seems more natural for this to me. It is sufficiently S-expression- 
> like, that I think we should try using term-trees for this.

I started out disliking the idea, but I don't see any serious reason  
it couldn't be made to work, and it would seem to be good to avoid  
duplication of similar tree-implementation/manipulation code.

(I feel that Kernel-E and full E should not be represented  
differently, in case you were suggesting that.)

> To the extent that term-trees currently can't handle this, perhaps  
> they should be fixed: Because term-trees are currently constrained  
> to be statically DeepPassByCopy, they can't contain Selfish objects.

E-on-CL's term implementation already relaxes this. See the  
parameterizable Term guard in

   lib/org/quasiliteral/term/makeTermAuthor.emaker

> As with E ConstLists, an individual term should be DeepPassByCopy  
> iff all its children are DeepPassByCopy. Further, a term could be  
> considered a term-tree iff all its children are smaller term-trees.  
> The determination that a term is a term-tree could be memoized.

ENodes have the special attribute of their staticScope. It would seem  
to be a good idea to define a general way to memoize analysis of trees.

Say, term.remember(function) would return whatever 'function 
(term)' (which is DeepFrozen) returns, but would store it in the  
term, in a map keyed by the function, if the term is DeepFrozen  
(which test is itself cached per term).

On the other hand, this would be useful in non-Term cases ("is this  
general object subgraph DeepFoo"), so perhaps the solution shouldn't  
be term-specific. I don't know what the right implementation would be.

(In general, such caching has the advantage (over a limited-size-map  
memoizer) of immediately discarding no-longer-useful results via GC  
without needing weak refs, and no assumption about working set size.)



-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>