5 ms·

Flexible in a way, sure. But non-locality is generally a bad property, not good. Adding it is a workaround for all the enumeration methods using blocks in a way

• vidarh 1y ago
  It's really not that complex. For my (buggy, unfinished, languishing without updates) prototype Ruby compiler, lambda and proc (and blocks) are all implemented nearly the same way, with the exception that for proc/blocks, return/break/next will act as if having unwound the stack to the scope where the proc was defined first (or throw an error if escaped from there). The distinction is very obvious when you think of it in that way - a proc acts as if called in the context/scope it was defined, while a lambda acts as if called in the scope it is called in. > How do you as a method author opt in to distinguishing between the two after yielding to a block? You don't. A block acts as a proc, not a lambda. If you want lambda semantics, then take a lambda as an argument - don't take a block/proc and be surprised it doesn't act like something it isn't.
  • chowells 1y ago
    Given that you completely ignored what I said I wanted to do and gave an answer for some other question, I'm pretty sure it's more complicated than you think. I want to write a method that takes a block and distinguishes between next and break, exactly like the methods of enumeration do. It's obviously possible because a super common interface does it. Last time I looked, that interface does it by being written in native code that interfaces with the interpreter. That is, it's not part of the language semantics. It's a special case with weird rules unlike what anything else gets to do. Or at least it was. Maybe the language has actually made it accessible since then, but I'm not optimistic. That's not the ruby way.
    • kayodelycaon 1y ago
      I think you’re seeing the base language. Effectively blocks are self-contained chunks of code. You can change things around them, but you can’t change how keywords work inside them. Because you’re crossing a method boundary when you call a block you’re not able to access next and break. (Or capture return.) Ruby is defining scope here and C methods are not limited by the language they define.
      • vidarh 1y ago
        Exactly. You can leverage some of the standard library methods to figure out if a block did a next or exit normally vs. did a break, by e.g. abusing Fiber's (there are probably other ways too), and that might feel a bit dirty, but those are also part of the language. I think it'd be nice if Ruby language constructs offered a few of the building blocks used by the standard library so that you could implement more of the standard library without dipping down into some low level mechanism - for my prototype Ruby compiler a priority was to implement as much as possible in Ruby, and there are certainly more things in the core classes that can't be done in pure Ruby than I'd like. But it's not that much, and while there are plenty of warts, the inconsistencies are often smaller than people think.
    • vidarh 1y ago
      Your sentence structure did not at all make it clear that "the two" referred to next and break rather than proc and lambda. Assuming you don't care whether a "next" was actually called, but only whether you've exited the block and whether or not you exited it via a break, you can do this check in a number of ways, but it I will agree it's a bit dirty that sometimes you do need to rely on standard library functionality rather than language constructs if you want to do these things. Here's one way of doing it, since "break" within a Fiber triggers a LocalJumpError: def next_or_break(&block) Fiber.new(&block).resume :next_or_end_of_block_reached rescue LocalJumpError :break end p(next_or_break do next end) p(next_or_break do break end)
      • dragonwriter 1y ago
• drnewman 1y ago
  It seems you're pretty upset about your experience with Ruby. I'm sorry that's been the case for you. However, in Ruby blocks aren't just about flexibility, more importantly they're about generality. They're not there to resolve an edge case at all (Ruby also has keywords for loops). They're a generalization of control flow that is just slightly less general than continuations. In practical use they provide an alterative to Lisp macros for many use cases. These were some of the problems Matz was trying to sort out with his design of Ruby--creating a language that was fun and easy to use for day-to-day programming, with as much of the meta-programming power of Lisp and Smalltalk as possible. Blocks are one of his true innovatations that came from trying to balance that tension.
  • igouy 1y ago
    > Blocks are one of his true innovatations … How do they differ from Smallalk blocks? (I don't know.) https://drcuis.github.io/TheCuisBook/Block-syntax.html https://drcuis.github.io/TheCuisBook/Block-syntax.html
    • drnewman 1y ago
      Blocks in Smalltalk (to my understanding) are closures. Blocks in Ruby are closures that also bring the call stack they were created in with them. One way to think of about it is this: anonymous functions as originally implemented in early Lisps are code as an object, closures are code with its lexical environment as an object. You can think of a Ruby block as code with its lexical environment and its call stack as an object. So they don't just handle return differently than closures, they have access to the call stack of the site where they're created like a continuation. This is why they handle return differently, but this is just one of the things that falls out from that. It also comes with other control flow features like "redo", "retry", "next", "rescue", "finally", and others. These are all call stack control (control flow) conveniences, just like return is. All of them can be thought of as being abstractions built on top of continuations (just ask a Scheme hacker). Originally Ruby was basically a Lisp without macros, but with continuations, a Smalltalk like object system and a lot of syntactic affordances inspired by Perl, and other languages. Blocks are one of the conveniences built on top of the Lispy semantics. Note that I'm explaining how blocks work as an abstraction (vidarh below explains how they work as a concretion, as implemented in MRI).
• pmahoney 1y ago
  Can you explain further? I'm not sure I follow. > How do you as a method author opt in to distinguishing between [break and next] after yielding to a block? I don't use Ruby much lately, but if I yield to a block which calls break, control will pass to the code following the block (and not back to my method). If the block calls next or simply finishes, control passes back to me though I cannot know if next was called or not (but do I care? I can go ahead and yield the next element of a collection either way)
  • chowells 1y ago
    Ah, you're right. They do have observably different behavior. But I can't even close an open file handle after a break. That's still pretty miserable.
    • HellzStormer 1y ago
      Yes you can, you use a finally clause around your call to yield, as you would already do to handle possible exceptions happening in the block. So no extra consideration is needed.
    • dragonwriter 1y ago
      > But I can't even close an open file handle after a break. Yes, you can. That's what ensure (the Ruby equivalent of "finally") is for. Or, better using File.open with a block where you do the work, which uses ensure under the hood.
• dragonwriter 1y ago
  > have fun working out the semantics of break and next when used in a block that isn't an argument to an enumeration method. The semantics are: * next returns from the block, optionally taking a return value that will be returned as the result of the function (this is identical to the behavior of "return" from a Proc with lambda semantics) * break returns from the function that yielded to the block, optionally taking a return value that will be returned as the result of the function (EDIT: deleted comparison to returns from a Proc with proc rather than lambda semantics here, because it wasn't quite accurate.) This is, incidentally, also exactly the semantics when they are called from a block passed to an enumeration method, there is no special case there. > How do you as a method author opt in to distinguishing between the two after yielding to a block? If control returns to your method, it was a return from the block, either via return (from a block with lambda semantics), next, or running through the end of the block. If, OTOH, break is called (or return from a block with proc semantics), control won't return to the calling method normally, but code in any "ensure" sections applicable will be run, which can be used to identify that this has occurred, and even to override the return value provided by the break. The simplest possible function illustrating this: def how_exited yield direct = true return "next, completion, or lambda return" rescue direct = true return "exception" ensure return "break" if not direct end