On Wed, Aug 02, 2006 at 06:41:19AM +0900, ara.t.howard / noaa.gov wrote:
> 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:

So are "sex" and "reproduction", but they're not the same thing, and
they are defined differently.  Thus, just as the definition of
"reproduce" doesn't provide a definition of "sex", so too "enclosure"
doesn't provide a definition of "closure".


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

That's a howto for creating closures, not an authoritative reference on
the history of the term "closure".  It doesn't even prove your point,
for that matter.


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

No, it refers to "closing" the scope, not "enclosing" the scope.  To
enclose the scope, you have to be outside of it.  To close the scope,
you seal it up so that stuff doesn't wander in and out of it.  By the
same token, if you close a door, you seal the passage against traffic in
and out: if you enclose a door, you're probably wrapping it up for
shipping.


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

I don't assume that to have inflammatory intent.  I only assume you're
confused about the difference between "close" and "enclose".


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

Read Intermediate Perl, then come back and say that again.

I will quote from its original version (which actually had a different
title, but it's still the first edition of Intermediate Perl) for you:

  The kind of subroutine that can access all lexical variables that
  existed at the time it was declared is called a _closure_ (a term
  borrowed from the world of mathematics).

. . . and again:

  This subroutine is a closure because it refers to the lexical $count
  variable.

  At the end of the naked block, the $count variable goes out of scope.
  However, because it is still referenced by the subroutine in
  $callback, it stays alive, now as an anonymous scalar variable.

Here's another quote from the same book:

  Closures are "closed" only on lexical variables, since lexical
  variables eventually go out of scope.  Because a package variable
  (which is a global) never goes out of scope, a closure never closes on
  a package variable.  All subroutines refer to the same single instance
  of the global variable.

(meaning: global to the "package", aka "namespace")

Here's yet another:

  A subroutine doesn't have to be an anonymous subroutine to be a
  closure.  If a named subroutine accesses lexical variables and those
  variables go out of scope, the named subroutine retains a reference to
  the lexicals, just as you saw with anonymous subroutines.

There are four distinct sections of Chapter 6: Subroutine References
that deal specifically with closures -- thus the wealth of quotes on the
subject.

In case you're wondering about the credentials of the author of this
book, his name is Randal L. Schwartz.  You may have heard of the
"Schwartzian transform".

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
This sig for rent:  a Signify v1.14 production from http://www.debian.org/