[shadowbanned4]

> The block is free to return from its enclosing method, which effectively pops multiple frames, including foo and possibly more, off the stack.

As an aside, this is one of the key differences between a lambda and a proc. Last I checked, you can pass a lambda as a block, but it is implicitly converted to a proc.

[throwanem]

I'm glad you mentioned that! The existence of three distinct abstractions over the concept of function values is another good example of Ruby's flawed design.

[vidarh]

They're not three different abstractions.

The distinction between a block and a Proc is an implementation detail - an implementation can choose to always make blocks Procs (my experimental Ruby compiler does just that) and a program shouldn't be able to tell the difference.

The distinction between proc and lambda with respect to how returns are handled provides significant utility with very low added implementation complexity that for the most part work together to do what people will expect of them.

That is, the most logical reading of the block syntax is that a return will return from the function it is lexically in, so it does, while a lambda looks like a function, and acts accordingly.

If anything, to me these are prime examples of what makes Ruby a great language that values developer happiness over pointless exercises in purity.

[djur]

Unlike JavaScript, which only has, uh, three (functions, arrow functions, and methods).

[throwanem]

No, Javascript has functions. That arrow functions handle the "this" binding specially I'll grant as a potential design error, and certainly as a complication; to reiterate, I have not said Javascript is perfect. But classes and methods are sugar over prototype-based objects from 1995, which you are still perfectly free to write if you like.

[masklinn]

> That arrow functions handle the "this" binding specially

It’s more the opposite, arrow functions treat `this` as a regular lexical variable, it’s normal functions which special-case `this`.