3 ms·
I've been thinking about block implementation off and on for a while (hobbyist language designer here) and I'd like to try implementing them so that they are ne
by ericbb 14y ago
I've been thinking about block implementation off and on for a while (hobbyist language designer here) and I'd like to try implementing them so that they are never values in the language semantics.
That way, a class of errors becomes impossible; namely, those errors that involve returning from a block whose method has already returned. I would have closures in the language but they would be just like Scheme closures: they would be independent of their creation context except for lexical bindings. I would compile blocks right into the method in which they appear.
Unfortunately, I don't have experience with any language that uses blocks. I'm quite familiar with closures but not blocks. I'm wondering if any Ruby or Smalltalk (or ...) programmer can give some reasons why blocks ought to be values.
Also, (referring to the post) does anyone know why rb_block_t was not embedded in rb_control_frame_t? That's the usual idiom in C and I can't think of a reason not to use it.