On Wed, 2008-01-09 at 04:32 +0100, Achim Schneider wrote: > Derek Elkins <[EMAIL PROTECTED]> wrote: > > > On Wed, 2008-01-09 at 03:37 +0100, Achim Schneider wrote: > > > Derek Elkins <[EMAIL PROTECTED]> wrote: > > > > > > > On Wed, 2008-01-09 at 00:51 +0100, Achim Schneider wrote: > > > > > Fernando Rodriguez <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Is currying in Haskell the same thing as Partial Evaluation > > > > > > (http://en.wikipedia.org/wiki/Partial_evaluation)? Am I > > > > > > getting partial evaluation for free just by using Haskell? > > > > > > > > > > > No, currying is this: > > > > > > > > No, it is not. This is partial application. See the wiki page > > > > Neil referenced. > > > > > > > Which works because of the functions being curried... > > > > and therefore partial application can't be currying. Currying is the > > operation of turning (a,b) -> c into a -> b -> c. Nothing more. > > > > > of course, the > > > usage is to "partly" apply a function, which is not possible, as all > > > Haskell functions are, by default, curried, and thus only have one > > > parameter, which can either be applied or not. > > > > Indeed. Partial application is a fuzzy term. I give a potential > > objective definition here: > > http://lambda-the-ultimate.org/node/2266#comment-33620 > > > Yes, it seems kind of obvious that eating a chicken isn't the same as > currying a chicken, but then there's a difference between eating > a grilled and a curried chicken... and cooking is always more complex > than eating. And you just can't have a curried chicken when there's > no one around that curries them. > > So, currying can also be the operation of turning > > (define (foo x y) (+ x y)) > > into > > foo x y = x + y > > or, mere syntactically, > > foo x y = x + y > > into > > foo = \x -> \y -> x + y > > > > > > > Partial evaluation, OTOH, goes into the direction of laziness vs. > > > eagerness: Iff the compiler sees that a thunk is only dependent on > > > data known at compile-time, it may choose to evaluate this thunk > > > already at compile-time, if you're lucky and the compiler isn't > > > lazy, > > > > Partial evaluation has little to do with lazy v. eager evaluation. > > > Well, enough for a thunk to be a reasonable metaphor for a candidate > partial evaluation. The compiler is eager, so that the result is > memoized before it is used... or not, but then that may not be > deducible for the compiler. It's a bit like stop and go traffic. > "Opportunistic evaluation" probably fits the concept better than > "eager". > > > Can we stop nit-picking, please?
Can we stop using confusing, misleading or outright wrong definitions and analogies? This is how we end up with people thinking 'currying' = 'partial application' = 'partial evaluation' or 'laziness' = 'memoization' or 'monads' = 'state passing' = 'continuations' or 'type classes' = 'OO classes' _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe