[e-lang] scoping rules of when-catch

[Mark S. Miller]

David Hopwood wrote:
> # This means that the user defined __if and __while constructs can properly
> # simulate the built-ins (except that the built-in 'while' can magically
> # bind __break and __continue, though the user-defined __while cannot).
> 
> What changes would be necessary to lambda-args to make exit constructs
> like 'break' and 'continue', and similar constructs for user-defined
> control abstractions, work correctly?


I think the answer must be "they can't". If they could, the whole rationale 
for user-defined control constructs 
<http://www.erights.org/data/irrelevance.html> would be violated. User-defined 
control constructs must be scope analyzable by the programmer when looking at 
a use occurrence without looking up or needing to know the defining occurrence.

A while construct like

     __while (condExpr) fn __break, __continue { bodyExpr }

would work, since the defining occurrences of __break and __continue appear 
explicitly. With pragma.enable("lambda-args") turned on, this expands to

     __while.fn__control_1_2(fn{
         [[condExpr], fn __break, __continue { bodyExpr }]
     }).run__control()

In the mangled verb name sent to __while, the "1" is the arity of the 
parenthesized expression list following the __while. The "2" is the arity of 
the function representing the body of that clause. The __while in the current 
E library does not currently respond to "fn__control_1_2", and I doubt we will 
extend it to do so. Instead, because of this issue, I expect the "while", 
"for", and "to" expansions to remain built in.

Note that the above doesn't quite succeed at simulating the semantics of the 
built-in while syntax. In the built-in while, __break is in scope for both the 
condExpr and bodyExpr. For both the built-in and the above example, __continue 
is in scope only for the bodyExpr.

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

     Cheers,
     --MarkM