[e-lang] scoping rules of when-catch

[Mark S. Miller]

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.

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

     Cheers,
     --MarkM