# Definitions of curry/uncurry (Haskell) Tweet

Computer Science and ICT discussion, revision, exam and homework help.

Announcements Posted on
Enter our travel-writing competition for the chance to win a Nikon 1 J3 camera 20-05-2013
IMPORTANT: You must wait until midnight (morning exams)/4.30AM (afternoon exams) to discuss Edexcel exams and until 1pm/6pm the following day for STEP and IB exams. Please read before posting, including for rules for practical and oral exams. 28-04-2013
So, my understanding of Currying is that it takes a function which takes two (or more) arguments, and returns a function that takes one argument.

So
add (x, y) = x + y
in curried form would be
(\y -> x + y)
Or more clearly as a new function addx
addx y = x + y

But in my lecture notes and the Haskell prelude according to this site http://bm380.user.srcf.net/cgi-bin/Prelude.txt
the definitions of curry and uncurry are

curry f x y = f (x,y)
uncurry f (x, y) = f x y

Which seems like the opposite of what currying is? This page seems to confirm my understanding of what 'currying' is, but the definition it gives seems to be at odds to the definition in the prelude:
f = curry g
g = uncurry f
f x y = g (x,y)

I think I have my head around the idea and reasoning behind currying (although feel free to point out any gaping misunderstandings), but I'd really appreciate an explanation of why the definitions of curry and uncurry seem so backwards. Am I just being stupid?

This describes it a bit more but it still seems backwards somehow.

curry's first argument must be a function which accepts a pair. It applies that function to its next two arguments. uncurry is the inverse of curry. Its first argument must be a function taking two values. uncurry then applies that function to the components of the pair which is the second argument.

EDIT: Well, I looked at it a bit more, and I think I understand it better now.

The exam it was for happened last week, anyway
Last edited by LtCommanderData; 17-06-2012 at 14:20.
It's been a while since you posted and nobody's replied yet...maybe you should check out MarkedbyTeachers.com, TSR's sister site. It has the largest library of essays in the UK.

They've got over 181,000+ coursework, essays, homeworks etc.. all written by GCSE, A Level, University and IB students across all topics. You get access either by publishing some of your own work, or paying £4.99 for a month's access. Both ways give you unlimited access to all of the essays.

All their documents are submitted to Turnitin anti-plagiarism software, so it can't be misused, and the site's used by hundreds of thousands of UK teachers and students.

What's more, you can take a look around the site and preview the work absolutely free. Click here to find out more...
3. Re: Definitions of curry/uncurry (Haskell)
(Original post by LtCommanderData)
So, my understanding of Currying is that it takes a function which takes two (or more) arguments, and returns a function that takes one argument.

So
add (x, y) = x + y
in curried form would be
(\y -> x + y)
Or more clearly as a new function addx
addx y = x + y

But in my lecture notes and the Haskell prelude according to this site http://bm380.user.srcf.net/cgi-bin/Prelude.txt
the definitions of curry and uncurry are

curry f x y = f (x,y)
uncurry f (x, y) = f x y

Which seems like the opposite of what currying is? This page seems to confirm my understanding of what 'currying' is, but the definition it gives seems to be at odds to the definition in the prelude:

I think I have my head around the idea and reasoning behind currying (although feel free to point out any gaping misunderstandings), but I'd really appreciate an explanation of why the definitions of curry and uncurry seem so backwards. Am I just being stupid?

This describes it a bit more but it still seems backwards somehow.

EDIT: Well, I looked at it a bit more, and I think I understand it better now.

The exam it was for happened last week, anyway
Just in case you haven't resolved it (and I hope the exam went well):

I find it helps getting your head around it if you bracket the function according to operator precedence (with functional application being the highest precedence, associating to the left).

Code:
`curry f x y = f (x, y)`

I suppose at first glace it may look like it is taking a curried function "f x y" and outputting an uncurried function "f (x,y)"

However what is actually happening:

Code:
`(curry f) x y = f (x, y)`
Meaning that you are passing x and y to "(curry f)", which as you should be familiar with is just the normal way of passing arguments to a curried function.
4. Re: Definitions of curry/uncurry (Haskell)
(Original post by Fallen)
Just in case you haven't resolved it (and I hope the exam went well):

I find it helps getting your head around it if you bracket the function according to operator precedence (with functional application being the highest precedence, associating to the left).

Code:
`curry f x y = f (x, y)`

I suppose at first glace it may look like it is taking a curried function "f x y" and outputting an uncurried function "f (x,y)"

However what is actually happening:

Code:
`(curry f) x y = f (x, y)`
Meaning that you are passing x and y to "(curry f)", which as you should be familiar with is just the normal way of passing arguments to a curried function.
Ah, yes, that is a useful way of looking at it, thanks!

I thought IP went better than DAA+FP, but that wasn't too bad, either. How did you find them?
5. Re: Definitions of curry/uncurry (Haskell)
(Original post by LtCommanderData)
Ah, yes, that is a useful way of looking at it, thanks!

I thought IP went better than DAA+FP, but that wasn't too bad, either. How did you find them?
DAA+FP was ok, IP was ok, but the CS Linear Algebra was bad, and our DS+Logic was only ok.

The sad thing about our Linear Algebra is that it is pitifully easy, I couldn't know the theory better, I just kept getting the wrong numbers out of my matrix multiplies / finding Eigenvalues. I spent over an hour trying, still couldn't get it to work (silly arithmetic errors), and so in the end had to do different questions.
It still went well, but everyone else would have got 20/20 on the disgustingly easy number-manipulation questions...

It is so hard to say though. I was very much aiming for a 1st, and I haven't totally given up hope, but I guess a 2:1 is more likely (and if I haven't got a 2:1 well...).