[e-lang] StaticScope's hasMetaStateExpr definition

[Kevin Reid]

On Feb 27, 2006, at 14:15, Mark S. Miller wrote:
> Kevin Reid wrote:
>> 1. Is hasMetaStateExpr used in ways which would be incompatible  
>> with  redefining it as ["does this ENode contain a reference to  
>> some noun or a MetaStateExpr that is not inside an intervening  
>> ObjectExpr"]? If not, should we introduce a separate flag  for it?
>
> ... For that operation, I like the name you use below:  
> hasOuterMetaStateExpr.

Agreed.

>> 2.
>> ...
>>   to uses(noun) :boolean {
>>     return namesUsed.maps(noun) || hasOuterMetaStateExpr
>>   }
>> )
>
> I think this operation would be a good idea.

I have made a note to add both 'uses' and 'hasOuterMetaStateExpr'.

> There is currently a similar optimization in E-on-Java's  
> BindFramesVisitor#visitEscapeExpr. But because it uses  
> hasMetaStateExpr, it is too conservative in just the way you point  
> out. It should be changed as you suggest.

Are there any other optimizations I should look at in  
BindFramesVisitor or elsewhere?

(I've mostly refrained from adding Kernel-E optimization operations  
since I hope for the Lisp compiler to do the heavy lifting, but I did  
this EscapeExpr elimination because ejector construction was showing  
up in a profile, and is the sort of thing that's hard to determine is  
deletable from looking at the code that implements it.)

> But I think the real answer is to get rid of meta.getState() from  
> Kernel-E. Instead, in a scope containing x and y, the expansion  
> from Expanded-E to Kernel-E should expand
>
>     meta.getState()
>
> to
>
>     ["&x" => &x, "&y" => &y]

What, then, does e`meta.getState()` return? Currently, expansion (as  
I know it) can be performed without any known lexical environment.  
Changing this should be considered with extreme caution.

Also, what exactly is 'Expanded-E'?

> Currently, a cycle containing a meta.getState() on the right is not  
> handled correctly, and it is hard to see how it could be.
>
> What does E-on-CL currently do on this case?

E-on-CL currently uses E-on-Java's expander, from necessity (and the  
ANTLR branch, while it implements expansion itself, is not  
specifically different), so it is treated identically:

e-on-cl? thunk { def x := meta.getState() } ()
# value: [].asMap()

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