3 ms·

I think it’s not as widely recognized as it could be just how forward-looking ECMAScript was in introducing language updates in the mid 2010s. For instance, arr

I think it’s not as widely recognized as it could be just how forward-looking ECMAScript was in introducing language updates in the mid 2010s. For instance, arrow functions make it natural to work with partial application, a currying-adjacent technique. const times = a => b => a * b const double = times(2) const twiceFour = double(4) As a language feature, a function to curry a given function is different from proper tail calls in that it can be implemented as a JavaScript function rather than needing to be built into the JavaScript engine. Similarly, Haskell’s own curry function is imported from its standard prelude. Leaving this detail up to language users allows a diversity of approaches and vibrancy in the community. Lodash has had an implementation for a while: https://github.com/lodash/lodash/blob/0843bd46ef805dd03c0c8d804630804f3ba0ca3c/lodash.js#L10200 https://github.com/lodash/lodash/blob/0843bd46ef805dd03c0c8d.... (Edit, found better example.) Structural pattern matching can be very elegant and it would be nice if ECMAScript offered it. Object destructuring has been added to the language, and that feature could be seen as a stepping stone for adding structural pattern matching in a later version. Proper tail calls however are more fundamental to the paradigm of functional programming, since they are necessary for iterative algorithms to work as well functionally as they do imperatively.

deleted 3y ago
[deleted]
MrJohz 3y ago
In Haskell, all functions are syntactically and semantically curried. That is, a function that takes two arguments is essentially identical to a function that takes one argument, and returns a new function that returns a second argument. (In fairness, part of this is the laziness of Haskell, and a language like OCaml which also uses currying behaves slightly differently, but still similarly enough.) The `curry` function is not a library implementation of currying, it's a way of unpacking tuples into arguments. In Javascript, a function that accepts two arguments is meaningfully different from a function that accepts one argument and returns a new function that accepts a second argument. Both semantically, but more importantly syntactically. It's possible to overcome this at the library level as you say, but it usually has performance and usability issues - error messages start looking very funky! It also often doesn't play well with other Javascript features, such as the famous `map(parseInt)` issue. That's not to say that currying isn't possible in Javascript, just that it's a feature that doesn't play well with the rest of Javascript. If you really want currying when you're coding, you're probably better off choosing another language - currying will work so much better, and you will have so many more advantages. What I've said is specific to currying, but in my experience, this is generally true. You can use certain functional idioms in Javascript (particularly higher order functions), but it isn't really a functional programming language. Adding features to make Javascript more functional makes the language a lot more complex, but it won't magically turn Javascript into a good functional language. Therefore, it doesn't make sense to include things in Javascript just because they're useful in a functional context, it's first important to validate that these features are useful in a standard Javascript context.
- hajile 3y ago
  JS works alright with currying, but I think manual currying is the best way to do it with the language (and it's not that inconvenient).

deleted 3y ago

[deleted]

MrJohz 3y ago

In Haskell, all functions are syntactically and semantically curried. That is, a function that takes two arguments is essentially identical to a function that takes one argument, and returns a new function that returns a second argument. (In fairness, part of this is the laziness of Haskell, and a language like OCaml which also uses currying behaves slightly differently, but still similarly enough.) The `curry` function is not a library implementation of currying, it's a way of unpacking tuples into arguments. In Javascript, a function that accepts two arguments is meaningfully different from a function that accepts one argument and returns a new function that accepts a second argument. Both semantically, but more importantly syntactically. It's possible to overcome this at the library level as you say, but it usually has performance and usability issues - error messages start looking very funky! It also often doesn't play well with other Javascript features, such as the famous `map(parseInt)` issue. That's not to say that currying isn't possible in Javascript, just that it's a feature that doesn't play well with the rest of Javascript. If you really want currying when you're coding, you're probably better off choosing another language - currying will work so much better, and you will have so many more advantages. What I've said is specific to currying, but in my experience, this is generally true. You can use certain functional idioms in Javascript (particularly higher order functions), but it isn't really a functional programming language. Adding features to make Javascript more functional makes the language a lot more complex, but it won't magically turn Javascript into a good functional language. Therefore, it doesn't make sense to include things in Javascript just because they're useful in a functional context, it's first important to validate that these features are useful in a standard Javascript context.

hajile 3y ago
JS works alright with currying, but I think manual currying is the best way to do it with the language (and it's not that inconvenient).