Hacker News Reader

Comment by jules | Hacker News Reader

They do have problems: 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, or you have to implement full blown first class continuations. You can then define call/cc in terms of non-local returns:

    function callcc(f){
      f(function(x){ return x })
    }

View on HN

> 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.

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