ZipPy status update
java at stefan-marr.de
Tue Dec 24 02:38:43 PST 2013
On 23 Dec 2013, at 16:41, Chris Seaton <chris at chrisseaton.com> wrote:
> Non-local returns in Ruby:
> Each method has a unique identifier allocated in the parser. The throw nodes also store this integer, and they put it into the ReturnException when they construct it. Then the ReturnException handlers check if the exception is meant for them, and if it’s not they re-throw it.
Ehm, does that work? Perhaps you are simplifying your explanation, but that sounds problematic for recursion. In TruffleSOM, I implemented that part with a FrameOnStackMarker that is part of the Arguments object. The ReturnException looks it up by walking the chain of lexical contexts and compares it when caught. That way, it’s definitely the correct dynamic point to return to.
> In Ruby it's very common to go through at least one scope like this - returns in a block within a method return from the method, not the block, even though the block is really a method in its own right. When the exception is finally caught I just return it as the return value from the execute method and it becomes a normal returned value.
> Note that in Ruby the return handler is a node all on its own. This logic isn't in RubyRootNode, RubyMethod, or the send node, like it looks like you are here. Methods which need it have a CatchReturnNode in their prelude. I also use this technique for things like checking that the number of arguments is correct.
> Then nodes which don’t ever catch returns, like blocks, don't even have this node to begin with.
Good, that’s what I was looking for. I am still missing a bit the intuition when to create nodes, but I think I am slowly getting there. I also created such a catch node now in TruffleSOM. Works ok, and makes inlining simple as well.
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
Phone: +32 2 629 2974
Fax: +32 2 629 3525
More information about the graal-dev