5 ms·
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 acti
by jules 15y ago
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 })
}
- munificent 15y ago> 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.
- wycats 15y agoNah. 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.
- deleted 15y ago[deleted]
- polotek 15y agoBut 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 }); }