ZipPy status update
chris at chrisseaton.com
Tue Dec 24 05:37:26 PST 2013
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.
puts "also doesn't reach here"
if f == nil
puts "doesn't reach here"
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