[drnewman]

I agree blocks are closures. But they’re call stack aware closures. Which gives them _some_ of the power of continuations.

I’m also sure you’re right that they’re not implemented using continuations. However, my understanding is that Ruby was originally conceived as a language with continuations. I’ll see if I can find a reference for that. But from what I recall reading in a blog post from someone who was at a programming language conference in 1997 when Matz introduced the language that’s how he described it.

[kazinator]

> they’re call stack aware closures

What does that even mean?

If you create a block deeply within a cascade of nested function calls, nineteen activation levels deep, and return that block out of all those nestings, is it still aware of the nineteen levels that have terminated, and to what purpose/benefit?

What example Ruby code would break without continuing access to the dynamic scope that has terminated, rather than just the lexical scope?

[dragonwriter]

> If you create a block deeply within a cascade of nested function calls, nineteen activation levels deep, and return that block out of all those nestings, is it still aware of the nineteen levels that have terminated, and to what purpose/benefit?

A block cannot be returned, because it is not an object; it has to be used to create a Proc object with either proc or lambda semantics to be returned.

With lambda semantics, its just a closure, doesn't care about the dynamic scope, and returns immediately to whatever calls it with return/next, or returns from the calling method with break.

With proc semantics, it does retain the connection, and return or break will result in an error when those scopes have terminated, but next will still return to the caller. (You don't generally want to return a proc for that reason, the use for procs is passing down a call chain, not returning them up.)

[drnewman]

Nice explanation

[kazinator]

OK, so we have gone from "blocks are continuations!" to "blocks (by themselves) are a kind of downward-funarg-only thunk!" (that can be used to specify the code part of a lambda or Proc, which are not continuations either).