Your explanation doesn't really explain currying. It actually explains the whole concept of partial application. Currying is in fact a very simple concept.
Imagine, that we have language where a function can be applied only to one argument - there are no multiple argument functions at all. What we can do in such situation to imitate multiple argument functions? We can write functions that return other functions.
For example, a function for two arguments is a function for one argument that take this argument and returns another function for one argument. Here is an example in JavaScript:
function sum(x) {
return (function(y) { return x+y });
}
Applying:
sum(2)(2)
Or in a sane language:
sum = \x -> \y -> x+y
Applying:
sum 2 2 --That's equivalent to '(sum 2) 2' because of application left associativity
Of course, for this trick to work our language should support closures (because the nested function capture a argument of its parent functon). But if you understand closures it shouldn't be a problem for you.
On Sunday, July 15, 2012 5:17:19 PM UTC+4, (unknown) wrote:
> I was reading/reminded that 'lambda calculus is not easy'.
> But I can't afford the effort to learn how to edit wikis.
> So I'll put it here:- [my wiki contaminated by my 'comments']
>
> > Currying may best grasped intuitively through the use of an
> > example. Compare the function (x, y) | x*x + y*y with its curried
> > form, x | (y | x*x + y*y). Given two arguments, we have:
> > ((x, y) | x*x + y*y)(5, 2) = 5*5 + 2*2 = 29. <-- f(5, 2) = 29
> > However, using currying, we have:
> > ((x | (y | x*x + y*y))(5)) (2) <--- (functn) (arg)
> >
> > (<1 arg> maps-to <lambda1Funct> (5) ) (2)
> >
> > = (y | 5*5 + y*y) (2)
> > = 5*5 + 2*2 = 29 <----------------- * !!
> > and we see the uncurried and curried forms compute the same result.
> >
> So what? That's not an intuitive explanation.
> Intuitive means related to concrete/familiar life.
>
> Eg. take a 3D/volume: semi-sphere, rect-cube or a 'wedge' is
> interesting; and place it on your x-y-coordinate 'pad'.
>
> The task/function is to know the <heights above your x-y-pad>
> of the top-surface. Like the heights of a mountain at a specific
> longtitude, latitude.
>
> For the wedge: if you know the x-value and the the y-value
> is constant at THAT x-value, you've got the answer.
>
> For the mountain: if you can only buy services of a flying-saucer
> that gives the longtitude-to-terain-height-function for a FIXED
> latitude, you've got the height, from you single parameter.
>
> So the set of (x,y) tuples & f1 is collaped into an eqivalent:
> [say] (x, y-cuts/slices/function) .
> By induction, it extends to N-dimensions.
>
> Here's a very intuitive example:
> the fare for transport is quoted in a table, as being a function of
> 'route' and class. Where route means 'A to B' equals 'B to A'.
> So 'Albany to Boston', class:2 costs $7,
> and 'Boston to Albany', class:1 costs $9.
>
> If you want to know the fare from 'Albany to Cooktown', class:3,
> you don't need to provide both paramenters: 'route' and class.
> You can just give the route, and ask for the singleton-function
> [list of all prices for 'Albany to Cooktown' for all classes].
>
> Thanks, I think I understand currying better now.
> Do you?
>
> == Chris Glur.
>
> PS. explanations that I have of 'monads' are disasterous.
On Sunday, July 15, 2012 5:17:19 PM UTC+4, (unknown) wrote:
> I was reading/reminded that 'lambda calculus is not easy'.
> But I can't afford the effort to learn how to edit wikis.
> So I'll put it here:- [my wiki contaminated by my 'comments']
>
> > Currying may best grasped intuitively through the use of an
> > example. Compare the function (x, y) | x*x + y*y with its curried
> > form, x | (y | x*x + y*y). Given two arguments, we have:
> > ((x, y) | x*x + y*y)(5, 2) = 5*5 + 2*2 = 29. <-- f(5, 2) = 29
> > However, using currying, we have:
> > ((x | (y | x*x + y*y))(5)) (2) <--- (functn) (arg)
> >
> > (<1 arg> maps-to <lambda1Funct> (5) ) (2)
> >
> > = (y | 5*5 + y*y) (2)
> > = 5*5 + 2*2 = 29 <----------------- * !!
> > and we see the uncurried and curried forms compute the same result.
> >
> So what? That's not an intuitive explanation.
> Intuitive means related to concrete/familiar life.
>
> Eg. take a 3D/volume: semi-sphere, rect-cube or a 'wedge' is
> interesting; and place it on your x-y-coordinate 'pad'.
>
> The task/function is to know the <heights above your x-y-pad>
> of the top-surface. Like the heights of a mountain at a specific
> longtitude, latitude.
>
> For the wedge: if you know the x-value and the the y-value
> is constant at THAT x-value, you've got the answer.
>
> For the mountain: if you can only buy services of a flying-saucer
> that gives the longtitude-to-terain-height-function for a FIXED
> latitude, you've got the height, from you single parameter.
>
> So the set of (x,y) tuples & f1 is collaped into an eqivalent:
> [say] (x, y-cuts/slices/function) .
> By induction, it extends to N-dimensions.
>
> Here's a very intuitive example:
> the fare for transport is quoted in a table, as being a function of
> 'route' and class. Where route means 'A to B' equals 'B to A'.
> So 'Albany to Boston', class:2 costs $7,
> and 'Boston to Albany', class:1 costs $9.
>
> If you want to know the fare from 'Albany to Cooktown', class:3,
> you don't need to provide both paramenters: 'route' and class.
> You can just give the route, and ask for the singleton-function
> [list of all prices for 'Albany to Cooktown' for all classes].
>
> Thanks, I think I understand currying better now.
> Do you?
>
> == Chris Glur.
>
> PS. explanations that I have of 'monads' are disasterous.