3 ms·

Typically, you can get the syntactic effect of Ruby blocks in a lisp using macros. Clojure tends to be a bit more anti-macro than other lisps, though and so thi

Typically, you can get the syntactic effect of Ruby blocks in a lisp using macros. Clojure tends to be a bit more anti-macro than other lisps, though and so this is less common than it would be in CL or Racket.

aeonik 3y ago
That makes sense, but isn't the Ruby &block evaluated dynamically? Lisp macros are expanded at compile time. From my limited understanding this would seem like a dynamic, run time, Lisp macro. But I don't know if the &block actually operates on the syntax. It looks it doesnt. From my research, it appears that blocks are more like a lambda that has an extra return statement bolted onto it. It also looks like you can pass them into methods to significantly alter what the method does, and how it returns. Pretty fascinating pattern. I'm not sure how I would implement something similar in Clojure. Maybe higher order functions, with lazy sequences combined with predicate checks.
- epcoa 3y ago
  Ruby blocks are just closures. They’re not macros as they don’t operate on syntax trees. Perhaps the person you are replying to was stating you can emulate some aspect of block syntax with a macro. If not, not sure what they’re saying.
  - fiddlerwoaroof 3y ago
    The reason people like blocks is that they give you a nice way to embed DSLs in Ruby code. The fact that they’re “just closures” seems like a secondary thing in most uses I’ve seen of them.
- fiddlerwoaroof 3y ago
  There’s a pattern called the call-with pattern that gives you this dynamic behavior of blocks. But, in many cases, Ruby and JS use this sort of dynamic “macro” where there’s not really a benefit to dynamic evaluation: with a macro you can always wrap the block of code with an anonymous function at macro-expansion time and opt-in to dynamic evaluation; Ruby blocks (and arrow-function DSLs in JS) force you to pay the overhead of dynamic evaluation even when you only need compile-time information

aeonik 3y ago

That makes sense, but isn't the Ruby &block evaluated dynamically? Lisp macros are expanded at compile time. From my limited understanding this would seem like a dynamic, run time, Lisp macro. But I don't know if the &block actually operates on the syntax. It looks it doesnt. From my research, it appears that blocks are more like a lambda that has an extra return statement bolted onto it. It also looks like you can pass them into methods to significantly alter what the method does, and how it returns. Pretty fascinating pattern. I'm not sure how I would implement something similar in Clojure. Maybe higher order functions, with lazy sequences combined with predicate checks.

epcoa 3y ago
Ruby blocks are just closures. They’re not macros as they don’t operate on syntax trees. Perhaps the person you are replying to was stating you can emulate some aspect of block syntax with a macro. If not, not sure what they’re saying.
- fiddlerwoaroof 3y ago
  The reason people like blocks is that they give you a nice way to embed DSLs in Ruby code. The fact that they’re “just closures” seems like a secondary thing in most uses I’ve seen of them.
fiddlerwoaroof 3y ago
There’s a pattern called the call-with pattern that gives you this dynamic behavior of blocks. But, in many cases, Ruby and JS use this sort of dynamic “macro” where there’s not really a benefit to dynamic evaluation: with a macro you can always wrap the block of code with an anonymous function at macro-expansion time and opt-in to dynamic evaluation; Ruby blocks (and arrow-function DSLs in JS) force you to pay the overhead of dynamic evaluation even when you only need compile-time information