[Haskell-cafe] Re: Currying and Partial Evaluation

[Achim Schneider]

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?

-- 
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.