Tag Info

Hot answers tagged

88

With curried functions you get easier reuse of more abstract functions, since you get to specialize. Let's say that you have an adding function add x y = x + y and that you want to add 2 to every member of a list. In Haskell you would do this: map (add 2) [1, 2, 3] -- gives [3, 4, 5] -- actually one could just do: map (2+) [1, 2, 3], but that may be ...


37

The practical answer is that currying makes creating anonymous functions much easier. Even with a minimal lambda syntax, it's something of a win; compare: map (add 1) [1..10] map (\ x -> add 1 x) [1..10] If you have an ugly lambda syntax, it's even worse. (I'm looking at you, JavaScript, Scheme and Python.) This becomes increasingly useful as you use ...


13

(I'll give examples in Haskell.) When using functional languages it's very convenient that you can partially apply a function. Like in Haskell's (== x) is a function that returns True if its argument is equal to a given term x: mem :: Eq a => a -> [a] -> Bool mem x lst = any (== x) lst without currying, we'd have somewhat less readable code: ...


13

Method chaining in object oriented languages is a little different from currying. By definition, the result of currying is a more restricted form of the original function. By convention, the result of method chaining is a modified form of the original (usually non-function) object. Method chaining can be used with unrelated methods on the same class, ...


10

TL;DR: No IMO Your question contains a bad assumption. Bad assumption there's nothing wrong with using a feature in moderation This is the wrong way to look at a language and it's capabilities. You should use whatever idiom, feature, etc, yields the shortest, most maintainable implementation that has reasonable performance for you/your team. It ...


10

Currying may be useful if you have a function that you are passing around as a first class object, and you don't receive all of the parameters needed to evaluate it in one place in the code. You can simply apply one or more parameters when you get them and pass the result to another piece of code that has more parameters and finish evaluating it there. ...


8

Currying is about turning/representing a function which takes n inputs into n functions that each take 1 input. Partial application is about fixing some of the inputs to a function. The motivation for partial application is primarily that it makes it easier to write higher order function libraries. For instance the algorithms in C++ STL all largely take ...


7

You are right in saying that what many (if not most) people in the JavaScript community refer to as currying does not really correspond to the term as defined in Haskell. Then again, neither does partial application. A partial application of all arguments is a full application, but this in not happening here, because if you do this for all arguments, you ...


7

I think both things are very closely related, and in the case of a two-argument function fundamentally the same really, although you could call the first thing you wrote as “complete” and the second one as “partial” currying, which would more precisely be called a special form of partial application or binding, always considering the first parameter. In ...


7

Like all choices in engineering, there is a definite trade-off. What is the benefit of replacing your existing code with your new trick? Is the code easier to maintain, easier to read (which aids in maintainability), is it faster, etc. Also, what are the downsides? Are you working in a team and, if so, does using your knew trick reduce readability for ...


7

The main motivation (at least initially) for currying was not practical but theoretical. In particular, currying allows you to effectively get multi-argument functions without actually defining semantics for them or defining semantics for products. This leads to a simpler language with as much expressiveness as another, more complicated language, and so is ...


7

Currying is not just syntactic sugar! Consider the type signatures of add1 (uncurried) and add2 (curried): add1 : (int * int) -> int add2 : int -> (int -> int) (In both cases, the parentheses in the type signature are optional, but I've included them for clarity's sake.) add1 is a function that takes a 2-tuple of int and int and returns an int. ...


6

But I can do the same thing (left-curry, right-curry, n-curry or partial application) by simply creating another named or anonymous function or closure that will forward the parameters to the original function (like tripler2) in most languages (even C.) And the optimizer will look at that and promptly go on to something it can understand. Currying is a ...


6

Currying is just syntactic sugar, but you're slightly misunderstanding what the sugar does, I think. Taking your example, fun add x y = x + y is actually syntactical sugar for fun add x = fn y => x + y That is, (add x) returns a function that takes an argument y, and adds x to y. fun addTuple (x, y) = x + y That is a function that takes a tuple ...


5

I feel that Jon Resig's curry function is misnamed, and is actually a form of partial application. Wikipedia actually has a well written section contrasting currying with partial application: Currying and partial function application are often conflated.[10] The difference between the two is clearest for functions taking more than two arguments. ...


5

Another thing I haven't seen mentioned yet is that currying allows (limited) abstraction over arity. Consider these functions that are part of Haskell's library (.) :: (b -> c) -> (a -> b) -> a -> c either :: (a -> c) -> (b -> c) -> Either a b -> c flip :: (a -> b -> c) -> b -> a -> c on :: (b -> b -> c) ...


4

Currying (partial application) lets you create a new function out of an existing function by fixing some parameters. It is a special case of lexical closure where the anonymous function is just a trivial wrapper which passes some captured arguments to another function. We can also do this by using the general syntax for making lexical closures, but partial ...


4

As @jk. alluded to, currying can help make code more general. For example, suppose you had these three functions (in Haskell): > let q a b = (2 + a) * b > let r g = g 3 > let f a b = b (a 1) The function f here takes two functions as arguments, passes 1 to the first function and passes the result of the first call to the second function. If ...


3

There are two key points about partial application. The first is syntactic/convenience -- some definitions become easier and shorter to read and write, as @jk mentioned. ( Check out Pointfree programming for more about how awesome this is! ) The second, as @telastyn mentioned, is about a model of functions and is not merely convenient. In the Haskell ...


2

Currying allows flexible function composition. I made up a function "curry". In this context, I don't care what kind of logger I get or where it comes from. I don't care what the action is or where it comes from. All I care about is processing my input. var builder = curry(function(input, logger, action) { logger.log("Starting action"); try { ...


2

For the function fun add(x, y) = x + y It is of the form f': 'a * 'b -> 'c To evaluate one will do add(3, 5) val it = 8 : int For the curried function fun add x y = x + y To evaluate one will do add 3 val it = fn : int -> int Where it is a partial computation, specifically (3 + y), which then one can complete the computation with it 5 val ...


1

Currying is an advantage when you don't have all of the arguments for a function. If you happen to be fully evaluating the function, then there's no significant difference. Currying lets you avoid mentioning not-yet-needed parameters. It is more concise, and doesn't require finding a parameter name that doesn't collide with another variable in scope (which ...


1

The primary reasoning I can think of (and I'm not an expert on this subject by any means) begins to show its benefits as the functions move from trivial to non-trivial. In all trivial cases with most concepts of this nature you'll find no real benefit. However, most functional languages make heavy use of the stack in processing operations. Consider ...



Only top voted, non community-wiki answers of a minimum length are eligible