[e-lang] scoping rules of when-catch

[Marc Stiegler]

Thank you. I knew what I meant, but said it so incorrectly even I can't 
tell I knew what I meant :-) I will rewrite this. I can surely make it 
correct, though whether I can make it understandable is a different issue.

The alternative solution that I have repeatedly thought about for Walnut 
is discarding the whole discussion in favor of simply using an anonymous 
name (underbar), which can never get you into this kind of trouble:

when (vowResolved) -> _ {
     #do something
} catch prob {
     #do something
}

Of course, I would put a discussion of the possibility of naming the 
darn things in the "advanced" section of the book.

The more I reflect on this, the more inclined I am to adopt it. But it 
will require a larger rewrite of the book, because I'd have to modify 
all the examples to use underbar as well.

--marcs


Toby Murray wrote:
> 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.
> 
>