From Whence can we return?

[apblack]

Where is a return statement legal in Grace? And what does it mean?

return is clearly allowed inside (any number of nested) blocks inside a method; executing the return returns from the enclosing method (with the return value, if provided, and with done if there is no return value).

Can return appear in a module, or in another object constructor? If so, what does it mean? Are there other places where we need to say that return can or cannot appear? Directly in a method? Directly in an object constructor (this is minigrace issue #325)? In a block inside an object constructor?

[KimBruce]

Return statements are allowed inside method definitions and result in terminating the execution of the method body and optionally returning a value. As I recall we had a little magic working to make sure returns in blocks execute a return from the methods containing them, e.g., if we have a user-defined control structure like

method m(...) {
    repeat (n) times {
         if (....) then { return }
         ...
    }
...
}

Is there a use-case for allowing returns elsewhere (e.g. in construction code for objects)? I can understand throwing exceptions, but I'm not sure what returns e.g. at the top level of a module, would return to.

[apblack]

I updated your example so that the return is inside a block, as Grace requires.

As you say, we can hardly outlaw exceptions inside object constructors, so we have to give them a semantics. I think that the semantics is clear: the object constructor never answers an object, but instead throws an exception. Hence, the expression executing the object constructor throws an exception, and so on.

The semantics of a return inside an object constructor is not so clear. @IsaacOscar had some expectations, which were unmet, but I don't think that the language spec says what should happen. I think that it should.

It seems to me that we have two choices.

1. The first is to say that return is allowed inside methods, but not inside modules or object constructors (except inside methods inside modules or object constructors). This is a bit tricky to write, because a return directly inside a method is useless; it's value is when the return appears inside a block inside a method that it's useful. Putting return in a place where it is not allowed is a syntax error. We get to decide whether we make return at the top level of a method an error or not; I'm inclined to leave that to dialects.

2. The second is to say that you can write a return wherever you want, but that executing a return that is not inside a method is a dynamic error, and will raise a nowhere to return exception.

We have to do something similar when a block containing a return is passed out of the method that created it. We could either (1) try to detect these situations statically (the general case is undecidable, I think), or (2) raise an exception dynamically "Sorry, that method has already returned" (which is what Smalltalk does.)

Implementation-wise, minigrace currently implements return using an exception, because JavaScript does not have non-local returns. This almost certainly plays havoc with the V8 optimizer. I have a long-term plan to replace these "return exceptions" with return codes that are checked after every method return. If we decide that the right semantics is (2), I would have to be careful to check these return codes after every JavaScript function call, including those that implement module initialization and object construction, as well as those that implement method request. But it should all be a mere matter of programming …