[Grace-core] Return

[Andrew P. Black]

On 29 May 2011, at 19:07 , Michael Homer wrote:

> Hi,
> I understand that "return" inside a block should return from the
> enclosing method.

Yes.  Assuming that you mean "statically enclosing method" — the method inside which the block was written.  I think that Kim's answer was assuming that it terminated the dynamically enclosing method.  I don't think that's what we want at all.

> What if that scope has already terminated? Is it a
> runtime error, or does it set the return value of Block.apply, pass
> silently, or something else?

It's a runtime error.

> 
> Two code examples:
>  method foo() {
>    return { return 1 }
>  }

The block returned from this method is useless.  Whenever it is applied, it will be a runtime error.

> and:
>  const a := object {
>    var block
>    method bar(block) {				--aka setBlock()
>      self.block := block
>    }
>    method baz() {				-- aka applyBlock
>      self.block.apply()
>    }
>  }
>  method foo() {
>    a.bar { return 1 }
>    ...
>    a.baz()
>    ...
>  }
>  foo()
>  ...
>  a.baz()
> 
> The second example contains both possible action at a distance and
> double-return.

I don't understand that terminology.  a.baz applies the block {return 1} and the execution of foo terminates.  What's a "double return"?

> 
> More generally, returning inside a block will cause execution of the
> scope invoking apply() to terminate as well, along with any others in
> between. Will the scopes be able to detect that?
> 
> I'm having difficulty finding an implementation strategy for this that
> covers all the possibilities. What I'm considering at the moment is
> roughly parallel to transforming "return x" to "block.hasReturned :=
> true ; raise Returns(v)" and writing the appropriate search in the
> exception handler, but that will still fall apart if the scope is
> either dead already or somehow not an ancestor of the apply() call. I
> have also considered providing the block with the creating scope's
> notional continuation, but that seems to have even more perverse
> results in these cases. I would like to be able to declare them to be
> an error or have undefined behaviour and just fail in the most
> convenient fashion.
> -Michael

Smalltalk has these semantics.  You might look and see how it is implemented.   I know that exceptions are NOT used; I don't see why any searching of the stack should be necessary.  The block simply contains a pointer to the stack frame in which it was created; that's the one that is terminated, along with all of the intervening frames.   One remaining issue is how to deal with "finally" clauses in terminated frames, but this is a general problem.

	Andrew