4 ms·

One issue with auto-currying is that, afaict, it prevents arity overloading. For example, I find this pretty silly: http://package.elm-lang.org/packages/elm-lan

One issue with auto-currying is that, afaict, it prevents arity overloading. For example, I find this pretty silly: http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Json-Decode#map6 http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Jso... One feature that always impressed me is how Kotlin has bring-your-own-chaining methods defined on everything. request(url).let { req -> req.setQuery(mapOf("a" to 42)) }.let { it.body = "foo" }.apply { // `this` is implicit receiver inside apply() send() } Not the best example of how it's useful because I'm rusty, but it's nice to just chain your own transformations on anything. I miss it all the time.

yorwba 9y ago
You can do arity overloading with curried functions if you allow overloading the function application operator itself. E.g. if f is of type A → B and a is of type Decoder A then map f a is of type Decoder B and in the special case where B is a function type C → D, that Decoder B = Decoder (C → D) can be applied to a value c of type Decoder C making map f a c a Decoder D. Caveat: I'm not aware of any language that actually does this, likely because redefining the core syntax of function application would be so easy to abuse. EDIT: Removed my Haskell example, because I think I got it wrong.
PeterisP 9y ago
In my code, the main use of arity overloading is to implement default parameters in Java, i.e., the feature has no intrinsic value, it's a workaround for the missing feature of default values; if a language has reasonable support for default parameters then arity overloading can go, leaving only type-dependent overloading.
bunderbunder 9y ago
At least in F#, I think that having too much need for arity overloading might be considered a code smell. In a nutshell, the idea is that, if you've got a bunch of functions with the same name but different arities, collectively they add up to a violation of the single responsibility principle. If you do need it, though, you can make a 1-arity function whose only argument is a tuple of a given size. This is how methods from C# and VB libraries are presented. I believe that it just compiles to a non-curried function behind the scenes.

yorwba 9y ago

You can do arity overloading with curried functions if you allow overloading the function application operator itself. E.g. if f is of type A → B and a is of type Decoder A then map f a is of type Decoder B and in the special case where B is a function type C → D, that Decoder B = Decoder (C → D) can be applied to a value c of type Decoder C making map f a c a Decoder D. Caveat: I'm not aware of any language that actually does this, likely because redefining the core syntax of function application would be so easy to abuse. EDIT: Removed my Haskell example, because I think I got it wrong.

PeterisP 9y ago

In my code, the main use of arity overloading is to implement default parameters in Java, i.e., the feature has no intrinsic value, it's a workaround for the missing feature of default values; if a language has reasonable support for default parameters then arity overloading can go, leaving only type-dependent overloading.

bunderbunder 9y ago

At least in F#, I think that having too much need for arity overloading might be considered a code smell. In a nutshell, the idea is that, if you've got a bunch of functions with the same name but different arities, collectively they add up to a violation of the single responsibility principle. If you do need it, though, you can make a 1-arity function whose only argument is a tuple of a given size. This is how methods from C# and VB libraries are presented. I believe that it just compiles to a non-curried function behind the scenes.