On Wed, 2 Aug 2006, Chad Perrin wrote:

>> because 'enclose' does not imply 'closed forever':
>
> We're discussing "closures", not "enclosures".

they are intimately related:


   http://en.wikipedia.org/wiki/Scope_(programming)

   ...

     Static scoping

     With static scoping, a variable always refers to its nearest
     ***enclosing** binding.  This is a property of the program text and
     unrelated to the runtime call stack.  Because matching a variable to its
     binding only requires analysis of the program text, this type of scoping
     is sometimes also called lexical scoping.  Static scope is standard in
     modern functional languages such as ML and Haskell because it allows the
     programmer to reason as if variable bindings are carried out by
     substitution. Static scoping also makes it much easier to make modular
     code and reason about it, since its binding structure can be understood in
     isolation. In contrast, dynamic scope forces the programmer to anticipate
     all possible dynamic contexts in which the module's code may be invoked.

     Correct implementation of static scope in languages with first-class
     nested functions can be subtle, as it requires each function value to
     carry with it a record of the values of the variables that it depends on
     (the pair of the function and this environment is called a ***closure***).
     When first-class nested functions are not used or not available (such as
     in C), this overhead is of course not incurred. Variable lookup is always
     very efficient with static scope, as the location of each value is known
     at compile time.

   ...

>>
> Two definitions of "closure" from the American Heritage Dictionary of
> the English Language:
>
>  A bringing to an end; a conclusion: finally brought the project to
>  closure.
>
>  The property of being mathematically closed.
>
> In fact, the term "closure" in computer science is derived from the
> mathematical definition of "closure", as in "a closed system".  A closure in
> computer science is code and data that constitute a closed system.

no, that's simply not correct.  the basis for the word 'closure' in computer
science refers to 'enclosing' the present scope.

take

   http://www.perl.com/pub/a/2002/05/29/closure.html

as an example of this interpretation.


> As David has suggested (without specifically and explicitly saying it
> outright in such terms), the data in question might consist of a sort of
> "potential data" such that a closure's referent closed scope needn't
> necessarily actually contain anything, so long as the scope itself is
> theoretically present and accounted for.

and 'scope' is the key here.  closure in computer science refers to enclosing
the present scope.

> If anything, it's you who's introducing pollutants to the otherwise clearer
> (if not actually clear) subject by confusing "enclosure" with "closure".

well, at the risk of sounding inflamatory, you're example and comments so far
have shown a decided lack of understanding about ruby's scoping rules and how
they related to a (common) notion of closure which is not 'closed' but is
enclosing.

your critique leaves one asking: what do __you__ think a closure should be
since what a closure actually is in ruby, perl, and many functional languages
is not closed at all.

in any case it's my hope that people realize that, whatever you call it,
ruby's closures do, in fact, act to enclose the existing scope and never
freeze or copy it.

regards.

-a
-- 
we can never obtain peace in the outer world until we make peace with
ourselves.
- h.h. the 14th dali lama