[e-lang] scoping rules of when-catch

[Toby Murray]

Mark S. Miller wrote:

> Toby Murray wrote:
>
>> From what I've read in MarcS' "Walnut" and the tutorial on erights.org,
>> it says that when using nested when-catch statements, one must avoid
>> doing things like the following, where we re-use the name "done"
>>
>> def func1 := { .... }
>> def p1 := func1 <- run()
>> def p2 := func1 <- run()
>> when (p1) -> done(v1) :any {
>> when (p2) -> done(v2) :any {
>> } catch prob {
>> }
>> } catch prob {
>> }
>
>
>
> If Walnut says this, it is wrong.


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

Walnut also says the following which does appear to be referring to the 
FQN clash rather than the scoping (non)issue.

---- begin quote ----
Under the covers, the "done(value)" part of the when-catch is actually 
the definition of a function. You can make up your own names for "done", 
such as "finished". Indeed, if a single object uses more than one 
when-catch, each "done" function must have a distinct name, such as 
done1, done2, etc.
---- end quote ----

I expect that it should be "... if a single method uses more than one 
when-catch" rather than "... if a single object ...". With that said, 
what is the actual ramifications when two fully qualified names clash? 
How seriously should programmers take the "*** conflicting definitions 
of __main$outer__C$foo__C" warning?

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

> The real issue that Walnut was trying to get at is a different
> counter-intuitive aspect of the scoping of these done functions; the 
> one you
> demonstrate below.
>
> The problem isn't a scoping problem in the traditional sense. Rather, it
> is a problem that arises in assigning fully qualified names to object
> definitions. 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
>
> There is no scoping ambiguity: Each "foo" variable exists in its own 
> scope,
> just like your above "done" functions. However, what fully qualified name
> should we assign to these functions? They both have the same local 
> name and
> the same enclosing object-definition expression, so they would both be
> assigned the same fully qualified name.
>
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...

>
>> It's all a bit confusing, really :)
>>
>> Can someone help me out here?
>>
>
> Does the distinction between scoping rules and fully-qualified name 
> assignment
> rules clear it up?
>
Indeed.


-- 
Toby Murray
Advanced Computer Capabilities Group
Information Networks Division
DSTO, Australia

IMPORTANT: This e-mail remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this e-mail in error, you are
requested to contact the sender and delete the e-mail.