Hacker News Reader

Comment by munificent | Hacker News Reader

> either you implement them partially and have gaps in your semantics so that returning from a function whose stack frame is no longer active raises an exception

Exactly right. That's the one nasty corner case I know of. I don't know how often it comes up in practice. I believe Ruby handles it by trying to make blocks not-very-first-class so that it's hard to capture one and have its extent outlast the outer stack frames.

View on HN

Nah. Ruby just raises an exception in this case:

  class BlockInvoker
    def initialize(&block)
      @block = block
    end

    def invoke
      @block.call
    end
  end

  BlockInvoker.new { puts 1 }.invoke

  def get_block_invoker
    BlockInvoker.new { return }
  end

  get_block_invoker.invoke

I tried to cover this a bit in my post. For callbacks, this semantic is clunkier.

But it's not such an edge case in javascript where asynchronous programming is the norm and stacks get thrown away all the time. In fact it's exactly the scenario that people will immediately try to solve with blocks, but they will fail.

function getMyData(input) { asyncDataCall(input, {|data| return data; // fail }); }

Reply on news.ycombinator.com