[Haskell-cafe] Re: Currying and Partial Evaluation

[Derek Elkins]

On Wed, 2008-01-09 at 04:32 +0100, Achim Schneider wrote:
> Derek Elkins <derek.a.elkins at gmail.com> wrote:
> 
> > On Wed, 2008-01-09 at 03:37 +0100, Achim Schneider wrote:
> > > Derek Elkins <derek.a.elkins at gmail.com> wrote:
> > > 
> > > > On Wed, 2008-01-09 at 00:51 +0100, Achim Schneider wrote:
> > > > > Fernando Rodriguez <frr149 at easyjob.net> 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'