Of closures and expressing anonymous functions [Was: Re: Securing a future for anonymous functions in Python]

[Simo Melenius]

bokr at oz.net (Bengt Richter) writes:

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

Which brings me to the point where I'd welcome more flexibility in
writing to variables outside the local scope. This limitation most
often kicks in in closed-over code in function objects, although it's
a more general issue in Python's scoping.

As we know, you can't write to variables that are both non-local and
non-global (globals you can declare "global"). Now that effectively
makes free variables read-only (although, the objects they point to
can _still_ be mutated).

Allowing write access to variables in a closed-over lexical scope
outside the innermost scope wouldn't hurt because:

1) if you need it, you can already do it -- just practice some
   cumbersome tricks make suitable arrangements (e.g. the classical
   accumulator example uses an array to hold the counter value instead
   of binding it directly to the free variable;

2) if you don't need or understand it, you don't have to use it;

3) and at least in function instances: if you accidentally do, it'll
   change the bindings within your closure only which is definitely
   less dangerous than mutating objects that are bound inside the
   closure.

It must be noted, however, that such behaviour would change the way of
hiding nested variable names:

Now it's safe (though maybe lexically confusing) to use the same
variable names in inner functions. This could happen with common names
for temporary variables like "i", "x", "y".

On the other hand, one could introduce a way to declare variables from
global scope or from local scope, with default from lexical scope. (If
you want to explicitly hide an outer binding, you'd declare "local
foo", for example. You can already do "global foo".)

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

I elaborated on this one in a post a few days ago. Indeed, it is
mostly a minor issue that _can_ be worked around(1). The problem is
that it eventually becomes irritating, when repeated all the time, to
name functions even if the name isn't used elsewhere.

It also creates an implicit dependency from the function call (one of
whose arguments points to the once-named function) to the once-named
function. That is, when you refactor some of your code, you must keep
two things paired all the time in your cut+paste maneuvers.


br,
S

(1) Everything can be worked around. In contrast: you can work around
the lack of a syntactic language by typing in machine code manually.
Sound stupid? Yes, it was done decades ago. How about using C to write
a "shell script" equivalent that you need, as a workaround to the
problem of lacking a shell? Stupid? Yes, but less -- it's been done.
How about writing callbacks by passing in a function pointer and a
data pointer, if you don't want to use a language like Python that
automates that task for you? Stupid? Yes, but not much -- it's been
done all the time. How about implementing an _anonymous_ function by
naming it, if you can't do it otherwise?