[Python-Help] data entry validation with Tkinter

[Alex Martelli]

"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'
variables.

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).


Alex