[e-lang] scoping rules of when-catch

[Marc Stiegler]

While I am a fan of the easy-when, I really want to introduce the 
when-catch first in Walnut, and use it almost exclusively until late in 
the book. It is important, I believe, to get people into the habit of 
thinking about the exceptional case when they are communicating over the 
wire. As we have discussed often, the chances of getting a failure when 
you are going over the wire are much greater than the chances of failure 
when you are just moving from one executed statement to the next.

You are not thinking of removing when-catch, correct? Just adding 
easy-when, right?

Mark S. Miller wrote:
> Toby Murray wrote:
>> Variations of the following sentences appear in both Walnut and "A 15 
>> minute introduciotn to E" (http://www.erights.org/elang/intro/quickE.html)
>>
>> ---- begin quote ----
>> "Nested when-catch clauses put the "done" functions into the same scope. 
>> In the actual example here, we gave the inner when-catch "done" function 
>> the name "done2" to prevent the name collision. We also gave the 
>> error-containing variables in the catch clauses different names, chevyE 
>> and mercedesE."
>> ---- end quote ----
> 
> 
> I've posted at <http://www.erights.org/elang/intro/quickE2.html> a draft 
> alternate version using the experimental "easy-when" syntax (see thread 
> containing 
> <http://www.eros-os.org/pipermail/e-lang/2004-December/010303.html>), in which 
> the done function does not appear.
> 
> To try this code out, you need to set:
> 
>      pragma.enable("easy-when")
>      pragma.enable("easy-return")
>      pragma.disable("explicit-result-guard")
> 
> If we all agree we like this style better, I'll adopt the easy-when option 
> into the official language, copy quickE2.html to quickE.html, and suggest 
> corresponding edits for MarcS to adopt into E in a Walnut. (Note that my 
> thesis already uses and assumes the easy-when style.)
> 
> 
>>> I just tried it, and the expansion is nested, as you'd expect.
>>>
>> Are you referring here to the expansion from E to kernel-E?
> 
> Yes.
> 
> 
>> I went 
>> looking on erights.org for the definition of what the "when-catch" 
>> expands to in Kernel-E and couldn't find it -- that's why I asked on the 
>> list. As an aside, how can one get access to the Kernel-E that the 
>> interpreter expands E code to?
> 
>      ? interp.setExpand(true)
>      ? 1 + 2
>      # expansion: 1.add(2)
> 
>      # value: 3
> 
> 
>>> Here is a simpler example of the same problem that 
>>> involves no when clauses:
>>>
>>> ? def outer() :any {
>>>> if (1 == 2) {
>>>> return def foo():any{}
>>>> } else {
>>>> return def foo():any{}
>>>> }
>>>> }
>>> *** conflicting definitions of __main$outer__C$foo__C
>>>
>> Without knowing the significance of fully qualified names (is there 
>> something I can read that tells me about these?), I'm presuming that 
>> something like an incrementing counter appended to the FQN isn't 
>> appropriate...
> 
> Correct. If you want an anonymous object definition expression, use "_" rather 
> than a variable name. For anonymous objects, E indeed generates unique fully 
> qualified names by incrementing a counter, just as Java does for anonymous 
> inner classes.
> 
> But for named objects, all of whose containing objects are named, these must 
> have fully qualified names that depend only on their package and containing 
> object names in the source code. This allows us to consider live-upgrading old 
> instances of such definitions to behave according to new definitions. If we 
> assigned FQNs automagically, these assignments would not be stable enough for 
> programmers to reason about upgrading old instances to instantiate new behavior.
> 
> Instances of anonymous object definitions are probably impossible to 
> live-upgrade, as there's no reasonable basis for saying which old definition 
> (in the old source tree) corresponds to which new definition. Smalltalk, whose 
> live-upgrade system remains the most impressive example I know of, does not 
> upgrade BlockClosures, probably for exactly this reason.
>