3 ms·

Currying is fun and I miss it sometimes as well, but as near as I can tell, it is essentially immiscible with traditional languages. I've seen so, so many attem

• hackyhacky 3y ago
  I agree that the Haskell approach is not easily portable to other languages. At least according to the article, the Ruby community is struggling to find a solution. I don't think parentheses (or their absence) is a decided factor: for example, I don't find the hypothetical Ruby syntax ["hello","goodbye"].map(&reverse) to be offensive or wildly inconsistent. Note that the map function itself doesn't need partial application, only its function parameter. For the same reason, I disagree that performance in dynamic scripting languages would suffer unduly.
  • zverok 3y ago
    > I don't find the hypothetical Ruby syntax ["hello","goodbye"].map(&reverse) to be offensive or wildly inconsistent. This syntax wouldn't work in Ruby, because bare `reverse` is already a method call, not a reference to a method by name. Allowing method calls without parentheses is crucial to Ruby's design, where all objects are fully opaque, and every `obj.attr` looking like a getter, is just a call to an instance method `attr`. (This is, as far as I understand, the opposite to similar languages like Python/JS, where the object is a dictionary of attributes, and `obj.method` reference the attribute of type "method", while `obj.method()` is an invokation.) This design became a huge drawback in the age of functional(ish) programming, because the simplest way for refer to a method in Ruby is `method(:its_name)` (which is also inefficient, because it creates wrapping object of class Method on the fly, there is no pre-existing first-class object), and any attempt of passing/combining methods would be cumbersome due to it. FWIW, you can do that in Ruby: (JSON.method(:parse) >> method(:puts)).call("[1, 2, 3]") ...which is semantically cool, but looks ridiculous. Another important trait of Ruby's design is that most of the important methods belong to their first argument, so it is not `reverse(string)` but `string.reverse`, so even to obtain a reference to a method, you need to have an object it belongs to! So you can't do that: method(:>).call(a, b) ...because all operators are called on their first operands, so you need this this: a.method(:>).call(b) ...which will require to refer to at least a first argument of the operator, so you can't produce "argument-less comparison operation to call later".
    • jerf 3y ago
      This is the sort of thing I meant by "essentially immiscible". At a 30,000 foot view, yeah, it looks like lots of languages could "just" add currying. But when you get down into the weeds of what it means, it turns out to be something you can't "just" drop in. You really need to build the syntax for it from day one.
    • dragonwriter 3y ago
      > you can't produce "argument-less comparison operation to call later". You absolutely can, if you know the specific one (that is, type) you need. E.g., gt = Integer.instance_method(:>).method(:bind_call) # gt is a two arg callable functionally equivalent to ->(a,b) { a < b } for Integer a, Any b Of course, doing this instead of just doing: gt = -> { _1 > _2 } loses Ruby duck-typing and dynamism with regard to the first parameter; which may be acceptable in some cases, but not others. Can you do the general form without an explicit lambda? Probably there is a way, but its not easy.
• Varriount 3y ago
  Surprisingly few attempts even seem to get over the bar of understanding what currying is, and why it isn't just partial application. Huh, what is the difference between currying and partial application? I always thought the terms were interchangeable.
  • dragonwriter 3y ago
    > Huh, what is the difference between currying and partial application? Partial application (of one arg) takes a function that is of type: (a, b, c) -> d And makes it: a -> (b, c) -> d Currying makes it: a -> b -> c -> d Ruby’s Proc#curry does magic that mostly lets you pretend its either or something in between.