Securing a future for anonymous functions in Python

[Bengt Richter]

On Thu, 30 Dec 2004 17:39:06 -0800, Jeff Shannon <jeff at ccvcorp.com> wrote:

>Bengt Richter wrote:
>
>> On Thu, 30 Dec 2004 15:15:51 -0800, Jeff Shannon <jeff at ccvcorp.com> wrote:
>> 
>>>Mimicking function-def indentation inside of another function's arglist 
>>>strikes me as an abomination just waiting to happen; in comparison, the 
>>>need to type a name twice seems trivial.
>> 
>> Self-restraint can avoid abominations ;-)
>
>It can, but given the prevalence of lambda abominations (such as the 
>many that the Martellibot described among Cookbook submissions), is 
>there any reason to believe that there would be *more* restraint in 
>using a less-constrained feature??  :)
Maybe. If people are determined to overcome limitations that needn't exist,
they are likely to invent horrible hacks ;-)

>
>>>As a result, it seems to me that, rather than generalize lambdas into 
>>>"full" anonymous functions (with most of the negatives and few of the 
>>>positives of lambda), it would be much better to specialize them further 
>>>into inline-closure-creators, where they can serve a valuable purpose 
>>>without quite as much risk of  code pollution.
>> 
>> (BTW, again, by closure, do you really mean deferred-action-thingie?)
>
>My understanding of "closure" (which may well be wrong, as I've 
>inferred it entirely from past discussions on this newsgroup) is that 
>it's a callable with some or all of its parameters already set; e.g.,
>
>     def one_and(foo):
>         def closure(arg):
>             return foo(1, arg)
>         return closure
>
>     incr = one_and(operator.add)
>
>The function one_and() returns a closure, here bound to incr.  It is 
>essentially a (partially) deferred action thingy, if you want to use 
>technical terms. ;)  I suppose that one could look at it as the 
>environment in which to call a given function, exported for later use...

Quoting from "Essentials of Programming Languages" (Friedman, Wand, Haynes):
(using *xxx yyy etc* for italics)
"""
In order for a procedure to retain the bindings that its free variables had
at the time it was created, it must be a *closed* package, independent of
the environment in which it is used. Such a package is called a closure.
In order to be self-contained, a closure must contain the procedure body,
the list of formal parameters, and the bindings of its free variables.
It is convenient to store the entire creation environment, rather than
just the bindings of the free variables. We sometimes say the procedure
*is closed over* or *closed in* its creation environment. We represent
closures as records.
"""

So it looks like you infer better than I remember, and attachment to
faulty memory has led me to resist better inferences ;-/

Closure is the name for the whole thing, apparently, not just the environment
the procedure body needs, which was the aspect that I (mis)attached the name to.

(Representing closures as records doesn't really belong in that paragraph IMO,
since it is not really part of the definition there, just a choice in that stage
of exposition in the book, using scheme-oriented examples. But I quoted verbatim.).

On the subject CLtL finally (after some stuff beyond my current caffeine level) says,
"""
The distinction between closures and other kinds of functions is somewhat pointless,
actually, since Common Lisp defines no particular representation for closures and
no way to distinguish between closures and non-closure functions. All that matters
is that the rules of lexical scoping be obeyed.
"""
I guess that clinches it ;-)

Might be a good python glossary wiki entry.

>
>My thesis here is that one of the most common (legitimate) uses of 
>lambda is as an adapter, to create an intermediary that allows a 
>callable with a given signature to be used in places where a different 
>signature is expected -- that is, altering the number or order of 
>arguments passed to a given callable (and possibly also capturing the 
>current value of some other variable in the process).  I feel that 
>it's more fruitful to focus on this "adapter" quality rather than 
>focusing on the "anonymous function" quality.
>
I see what you are saying (I think), but I think I'd still like a full
anonymous def, whatever adapter you come up with. And I prefer to be persuaded ;-)

Regards,
Bengt Richter