ZipPy status update

Chris Seaton chris at
Tue Dec 24 05:37:26 PST 2013

On 24 December 2013 10:38, Stefan Marr <java at> wrote:

On 23 Dec 2013, at 16:41, Chris Seaton <chris at> 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.

I investigated with a case that puts an activation in between the lexical
return point and the return statement, and you're right it doesn't work as
you might expect. However, it does pass all the relevant return tests in
RubySpec, so I don't know if it's a bug or not.

def run(&block)
  puts "also doesn't reach here"

def foo(f)
  if f == nil
    run do
      return 14
    puts "doesn't reach here"

puts foo(nil)

I believe this should print 14 (but who really knows in Ruby), but both the
'doesn't reach here' lines are executed.


More information about the graal-dev mailing list