ZipPy status update

[Chris Seaton]

On 24 December 2013 10:38, Stefan Marr <java at stefan-marr.de> wrote:

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.


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)
  foo(block)
  puts "also doesn't reach here"
end

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

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.

Chris