[Python-Help] data entry validation with Tkinter

Alex Martelli aleax at aleax.it
Wed Aug 8 13:35:40 CEST 2001

"Nicola Musatti" <objectway at divalsim.it> wrote in message
news:3B710C31.B7FADB0D at divalsim.it...
> Alex Martelli wrote:
> [...]
> > It's a little bit more work when you want to
> > pre-specify some of the arguments to be passed to the callable you
> > want (technically called 'currying', in honor of the great mathematician
> > Haskell Curry [...] )
> Whom, I guess, also unwittingly provided a name for a programming
> language.

Good guess.  It's just one more way in which he's been honored.

> Ahem, I realize it's somewhat OT, but could you explain the
> relation/difference between currying and closures?

Currying, at heart, is a way to look at functions: there is
no need to think of a function 'accepting multiple arguments'
as long as you're comfortable with higher-order functions
(functions returning functions).  Say you have a function f
which you may think of as taking two arguments a and b and
returning a 'something' we can call c: well, you can instead
see f as a function taking a SINGLE argument (a) and returning
a function (say g) which in turn takes argument b and returns c.
This is indeed (over-simplifying) from Curry's work, I believe.
So, the 'currying' we do (e.g. in Haskell:-) is just making
this explicit -- the function call syntax is
    f a b
which you may parenthesize as
    (f a) b
where (f a) is a function (the one we called g).

'Closure' is a rather overloaded term -- the standard math
definition for "closure of set S under function F" being
(something like) "the intersection of all supersets of S
that are closed under F" (where a set X is 'closed under F'
iff, for all i in X, F(i) is in X) -- basically, you can
think of a closure of a set S under a function F as: set
S; union with F(i) for all i in S; union with F(F(i)) for
all i in S; ... stopping when no more new items are added
to the set being constructed in one 'F(F(F...(i))) for all
i in S' step -- if you're more comfortable with such
informal but constructive style.  But I think this has
little to do with the normal Lisp definition, where a
closure can be thought of as a pair (function,
environment) -- an environment being a set of bindings
of names to values -- so no 'free' variables remain,
only formal-parameters to the function and 'bound'

If you take a step back from these issues and look at
it with slightly-fuzzy eyes -- in both cases we can
think of starting with a function which has some
not-yet-bound variables (formal arguments in one
case, free variables in the other) and returning
another function which has fewer n-y-b variables
(fewer formal arguments [1, by rigorous definition]
for currying, fewer free variables [0, by rigorous
definition] for closures).  So at an implementation
and usage level the two concepts aren't all THAT
far apart -- if we have a mechanism that binds some
of a function's "dangling" (not yet bound) names
(aka variables), we can use it to implement both
currying and closures, and not just in the rigorous
senses of the term but a more general one (letting
us keep some number of formal arguments that is
not necessarily exactly 1, or some number of unbound
variables that is not necessarily exactly 0).


More information about the Python-list mailing list