On Aug 19, Randal L. Schwartz wrote: > >>>>> "Kurt" == Kurt Starsinic <kstar@cpan.org> writes: > Kurt> It seems very strange to me to say that an anonymous sub with > Kurt> no private variables is "not a closure." Is not the (shorthand) > Kurt> definition of a closure "a subroutine, associated with all its > Kurt> bindings," even when "all" == 0? > > Well, we need a term for that then. I've been adovcating "closure" > as when "all > 0", whether named or anonymous. > > But if you have a better term (that doesn't take more than three > words) for the subroutines that generate a different CV when created > as opposed to those that don't, I'm all for it. I suggest that it's a closure when the language supports associating bindings to the subroutine. In Perl, this is always and only the case for anonymous subroutines, whether or not the number of private bindings > 0. So it seems to me that, in Perl, a named subroutine is never a closure, and an anonymous subroutine is always a closure. The fact that perl optimizes the special case of an anonymous subroutine with 0 private bindings is an implementation detail of interest to a tiny few. This behavior is not guaranteed, and based on Simon's bug, I suspect that it will change. > If "all subroutines are closures", then the term loses its usefulness > within the Perl world. I'm with you 100% there, Randal. - KurtThread Previous | Thread Next