[e-lang] scoping rules of when-catch -- Walnut text

[Toby Murray]

Some quick fixes might be as follows. (This list isn't exhaustive, though)

In the "Promises" section
http://www.skyhunter.com/marcs/ewalnut.html#SEC20

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.

could be changed to:

Under the covers, the "done(value)" part of the when-catch is actually 
the 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 you use more than one 
when-catch in the same scope, each "done" function should have a 
distinct name, such as done1, done2, etc. This restriction can be 
avoided, however, by defining an anonymous function by using the '_' 
underscore for its name.

In the "Nested When-Catch Constructs" section
http://www.skyhunter.com/marcs/ewalnut.html#SEC31

the code doesn't need to have the nested "done" use a different name, 
nor does the nested catch require a different name for the problem, so 
it could change to:

# E syntax
def fileRcvr := fileCacheRcvr <- getFile()
when (fileRcvr <- exists()) -> done(exists) {
    if (exists) {
        when (fileRcvr <- getText()) -> done(text) {
            println("File has text: " + text)
        } catch prob {println("Problem with existing file: " + prob)}
    } else {println("File does not exist")}
} catch prob {println("Problem reaching file: " + prob)}
    

  

The accompanying text could also be changed to the following:

Here, we want to print the text of a farFile, but we want to be sure the 
file exists first. So we ask the file if it exists, and only after we 
determine that it does indeed exist do we proceed to get the text.

As noted earlier, the "done(variable)" clause of the when-catch 
construct is actually the declaration of a function and a series of 
parameters. The reasons for this are beyond the scope of this book, but 
the operational consequence is that you must use different function 
names if you have multiple when-catch clauses in the same scope.

Fortunately, this restriction does not apply to nested when-catch 
clauses. As one would expect, a nested when-catch clause puts the inner 
"done" function within the scope of the outer "done" function. 
Similarly, the inner catch clause is within the scope of the outer done, 
so no conflict occurs by using the same name, "prob" for both 
error-containing values.



Hopefully, the above would fix the text Ok without requiring major 
changes and effort (like using the easy-when throughout).

Walnut is a great reference, by the way. I can only imagine the amount 
of effort it must be to put together something like that. Its breadth is 
pretty staggering. Have you considered putting it up as a (moderated) 
Wiki? I notice that there are a number of TODOs marked in the book. 
Perhaps a distributed book-hacking effort could help tie up the loose 
ends etc.


Marc Stiegler wrote:

>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.
>>
>>
>>    
>>
>
>_______________________________________________
>e-lang mailing list
>e-lang at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/e-lang
>  
>


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