[e-lang] StaticScope's hasMetaStateExpr definition

[Mark S. Miller]

This is in reply to old e-lang message
http://www.eros-os.org/pipermail/e-lang/2006-February/011133.html
See the original for the full context.

Kevin Reid wrote:
> 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.

The need for these two operations is now recorded as bug
https://sourceforge.net/tracker/index.php?func=detail&aid=1527148&group_id=75274&atid=551529


>> 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?

For some reason, BindFramesVisitor also optimizes

     if (true) {x} else {y}
to
     x
and likewise for
     if (false) {x} else {y}

These seem like silly optimizations, and should probably be removed, as in now 
recorded in bug
https://sourceforge.net/tracker/index.php?func=detail&aid=1527150&group_id=75274&atid=551529


>> 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'?

Expanded-E is the expansion of E performed by the e`...` quasi-parser. This 
expansion does indeed need to be context-independent, as otherwise one could 
not compose quasi-literal program fragments. Expanded-E gets further expanded 
to Kernel-E prior to evaluation. This latter expansion could depend on 
context, as suggested above. OTOH, if this only remaining case requiring us to 
distinguish Expanded-E from Kernel-E, then it would probably be better to 
collapse the Expanded-E vs Kernel-E distinction, and keep the MetaStateExpr in 
Kernel-E.

Currently, circular defines are expanded by the e`...` quasi-parser, but the 
determination of whether we have a cycle is exactly the sort of context 
dependency that creates quasi-literal composition problems. It is plausible to 
me that this may also move to the Expanded-E to Kernel-E expansion, in order 
to aid quasi-literal composition. What other cases are there?

This issue is now bug
https://sourceforge.net/tracker/index.php?func=detail&aid=1527152&group_id=75274&atid=551529

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM