Steven D'Aprano wrote:
y = 1
def func():
x = 2
return x+y
Here, there's a local environment as well as an implicit global one.
Surely we don't want to call this a closure?
Python probably isn't the best choice of language for the
point you're making, because even top-level functions in
Python *do* carry a reference to their environment (the
dict of the module they were defined in).
C would be a better choice:
int y = 1;
int func(void) {
int x = 2;
return x + y;
}
int (*fp)() = func;
Even here, I don't think there's anything wrong with calling
fp a closure. It's just that it's a particularly simple form
of closure -- since there's only one global environment, we
don't need to bother explicitly carrying it around.
However, that doesn't mean all functions are closures. An
example of a non-closure might be a C++ member function pointer.
It points to a piece of code, but you can't use it on its own,
because it's missing a piece of environmental information
(a value for "this") that you need to supply by hand when
you call it.
we have to consider what happens if we come
across a Pascal implementation which *doesn't* use a (code_address,
frame_pointer) pair. Is that no longer Pascal?
In anything that implements Pascal semantics, a function
parameter is going to have to be represented by *something*
that specifies both code and environment. Code alone is
not enough.
> If we accept that "Pascal has closures", they're pretty crap closures,
> since they don't let you do any of the interesting and useful things you
> can do in languages with "real" closures like Scheme and Python.
Not all of them, but it can do some of them. They're more
useful than in Modula-2, for example, where nested functions
can't even be passed as parameters.
Anyway, that's why I said "a limited form of closure". You
could read that two ways: (1) It's totally a closure, but
there are limitations on what you can do with it (i.e. it's
not first class). Or (2) it has some of the characteristics
of a closure, but not all of them.
In my mind I tend towards (1), but it doesn't really matter.
--
Greg
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
