[Haskell] curried and uncurried functions

[Haskell] curried and uncurried functions

Post by rincewin » Wed, 15 Nov 2006 04:37:58

Suppose you write some function of 2 (or more) arguments, and suppose
partial application of this function doesn't make much sense in your
program. Does it make sense still to create curried version of this
function? How do these 2 options compare in terms of costs?
For some reason, uncurried function seems more "basic", or "primitive"
to me, despite being slightly more verbose syntactically, so, if partial
application doesn't make much sense, I tend to create uncurried version.
What do you think, what other considerations might be considered here?

[Haskell] curried and uncurried functions

Post by Marcin 'Qr » Wed, 15 Nov 2006 21:31:08

rincewind < XXXX@XXXXX.COM > writes:

Yes: the Haskell tradition is to curry all functions with multiple
arguments, for consistency.

Except perhaps when a bunch of arguments is often passed around as
a whole. Then it might make sense to pack them in a single value.

Haskell compilers try to make curried functions fast, without
materializing the partial applications.

The same is true for OCaml. SML traditionally prefers uncurried
functions, but some are curried.

__("< Marcin Kowalczyk
^^ http://www.yqcomputer.com/ ~qrczak/


[Haskell] curried and uncurried functions

Post by Ben Rudiak » Wed, 15 Nov 2006 22:11:57

Probably the same, if you call the function directly. If you use it in a
higher-order context, the curried version will probably be a bit faster,
because a typical implementation will pass the curried arguments on a stack,
whereas a tuple argument will be constructed on the heap (and a pointer to
it passed on the stack).

Curried functions can be seen as more primitive in the sense that they only
use the notions of abstraction and application, whereas uncurried functions
need those and also a notion of tupling.

-- Ben