[E-Lang] the return of `return'

[Darius Bacon]

Dean Tribble <tribble@e-dean.com> wrote:

> I couldn't resist sending a message because this problem is so easily 
> addressed with the Scheme concept of syntactic environments.  I first 
> encountered the concept of syntactic environments (closures, scopes, etc.) 
> in Scheme work to *correctly* expand macros (called hygienic macro 
> expansion).  However, it applies to *any* program transformation work, and 
> so is an important concept for understanding transformation of E into 
> kernel-E, for example.
[...]
> >First, E has nested definitions -- which method do we return from?
> >Suppose it's the innermost.  Then
> >
> >    for key => value in collection { ... return(x) ... }
> 
> Method definition would define "return" in the syntactic scope of its 
> method body.  Remember, it is still just a simple variable definition after 
> alpha renaming, and so would be a legal E expression.  Thus,
> 
> >    collection iterate(def _(key, value) { ... return(x) ... })
> 
> wouldn't have a problem, as I will show in the example below, because the 
> reference to "return" would have been renamed to the "return" escape 
> defined by the function definition it was textually embedded in, not the 
> function definitions newly introduced by transformation (which would have a 
> different syntactic scope).

That's an excellent point!  This renaming is the `uglier expansion' I
had in mind, instead of Zooko's special kind of function def that
doesn't rebind `return', since the renaming doesn't need new syntax.
I just had a queer blind spot, thinking of it as hygienic only when
there's an explicit binding occurrence of the name.  I feel better
about this now.

[...]
> >    def fooMaker(x) {
> >        return(def foo {
> >            to blat() { ... }
> >        })
> >    }
> 
> With special syntax, the above would be:
> 
>     def fooMaker(x) {
>         return def foo {
>             to blat() { ... }
>         }
>     }

The `return' there still annoys me but it's not nearly as bad as with
the parens...

> or perhaps even
> 
>     def fooMaker(x) {
>         return foo {
>             to blat() { ... }
>         }
>     }

If this were the first code I saw then I'd be scratching my head
wondering what it means.

[...]
> Which immediately and trivially optimizes to
> 
>     def fooMaker(x) {
>         def foo {
>             to blat() { ... }
>         }
>     }
> 
> in kernel E, which is what you would expect.  Actually, you wouldn't even 
> insert and escape unless there was an embedded reference to it.

If this code is still valid Kernel E but full E requires `return',
then Kernel E is no longer an E subset.  One fix: require all Kernel E
object definitions to look like ``to foo() { return ... }'' and
translate any nonlocal returns to explicit escape expressions.

-Darius