[e-lang] makeProxy reveals implicit sendOnly

[Kevin Reid]

On Jun 3, 2007, at 22:37, Mark S. Miller wrote:

> Kevin Reid wrote:
>> I had understood that it is intended that <- is optimized to  
>> sendOnly when the result is not used; if so, then either the  
>> conditions for this optimization must be well-defined, or  
>> makeProxy must be unsafe.
>
> Good catch. I think I agree that these are the only viable choices.  
> Of the two, I mildly prefer the first: we should specify the  
> conditions in which this optimization happens.

I now see that this isn't a problem at all for <- in particular:

1. <- is not in Kernel-E and as such is expanded.

2. The expansion operation is exposed.

3. Therefore, the expansion of <- must be well-defined for  
independent reasons.

Optimising invocations of E.send to E.sendOnly would not have this  
independent reason, however.


Regarding the expansion of <-, here's a sketch of a rule. <- becomes  
sendOnly if it is found in an ignored-value position, where such a  
position is:

   * in a non-final position in a SeqExpr, or
   * in the body of a CatchExpr, EscapeExpr, FinallyExpr, or IfExpr  
which itself is in an ignored-value position.

However, the second part implies that the SendExpr is expanded after  
its enclosing node has been expanded, which is not necessarily the  
case in my expander; some node expanders (&&, ||, defrec, forward- 
def, =~, map export/import, :=, bind) expand their children first in  
order to perform static scope analysis or other processing.

As E-on-Java's expander already does, this could be solved by having  
the expansion operation take a specification of whether (or how) the  
result is to be used; however, I understand the existing usage does  
not affect the externally visible semantics of the code, unlike <-;  
this means it would need to be done more carefully.

On the other hand, how much does the exactness of the rule truly  
matter, as long as it's deterministic? Is it perhaps sufficient to  
say that if you want to reliably hide such information, you must use  
E.send/sendOnly explicitly (just as you might need to override  
__getAllegedType to hide those details)? I suspect that it is  
impractical to require that expansion is perfectly implemented.

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