I don't think this would fit in the normal CS definition of a closure.

I think the "normal CS definition of a closure" is a pretty elusive beast; mythical, maybe. I've been unsuccessfully looking for one since tye challenged me to find one in his reply to this node. Most of the time, the term is defined within the context of a particular language. Usually, it is demonstrated rather than defined at all.

Insofar as creating a definition, I disagree with tye about the importance of being able to "hide different lexicals into seperate refences to the same subroutine." (I absolutely agree that being able to do so is what really makes closures useful, however.)

If tye had tasked me with writing a generic definition for "closure" rather than finding one, I would have responded with something similar to this:

A closure is code that retains a binding to a free variable even after the variable has gone out of scope.

In your example you're moving to some code that's inside a scope, rather than creating some code that carries it's scope with it.

Well, yes and no. (And this is, at least in part, why I submitted it for discussion.) I suggested that the closure is actually created when the sub is first entered via the goto. At that point, the variable has gone out of scope. Then we jump back into the code after the declaration. Really, it's very similar to broquaint's "named closure" example; only, the inner block is not a subroutine. I don't know the details of what perl is doing with the relevant scratchpads at that point, and I'd be happy for someone to explain it to me. I suspect that the variable is re-initialized to undef because perl doesn't ever expect a bare block to be used like a closure but I'm not sure why it isn't consistently re-initialized (except that we never explicitly declare it again.)

Perhaps you disagree that a "named closure" is a closure at all and I suppose that is debatable. I think a "named closure" fits the definition that I gave above though, so I'm in agreement with broquaint when he says that he doesn't think the Camel (3rd edition) is entirely accurate in its "anonymous function" requirement.

-sauoq
"My two cents aren't worth a dime.";