Correct misleading definition of 'closure' in base/bind documentation.

base/callback.h.pump

 $$ This is a pump file for generating file templates.  Pump is a python
 $$ script that is part of the Google Test suite of utilities.  Description
 $$ can be found here:
 $$
 $$ http://code.google.com/p/googletest/wiki/PumpManual
 $$
 
 $$ See comment for MAX_ARITY in base/bind.h.pump.
 $var MAX_ARITY = 7
 
@@ skipping 10 matching lines @@
 
 // NOTE: Header files that do not require the full definition of Callback or
 // Closure should #include "base/callback_forward.h" instead of this file.
 
 // -----------------------------------------------------------------------------
 // Introduction
 // -----------------------------------------------------------------------------
 //
 // The templated Callback class is a generalized function object. Together
 // with the Bind() function in bind.h, they provide a type-safe method for
-// performing currying of arguments, and creating a "closure."
+// performing partial application of functions.
 //
-// In programming languages, a closure is a first-class function where all its
-// parameters have been bound (usually via currying).  Closures are well
-// suited for representing, and passing around a unit of delayed execution.
-// They are used in Chromium code to schedule tasks on different MessageLoops.
+// Partial application (or "currying") is the process of binding a subset of
+// a function's arguments to produce another function that takes fewer
+// arguments. This can be used to pass around a unit of delayed execution,
+// much like lexical closures are used in other languages. For example, it
+// is used in Chromium code to schedule tasks on different MessageLoops.
 //
+// A callback with no unbound input parameters (base::Callback<void(void)>)
+// is called a base::Closure. Note that this is NOT the same as what other
+// languages refer to as a closure -- it does not retain a reference to its
+// enclosing environment.
 //
 // MEMORY MANAGEMENT AND PASSING
 //
 // The Callback objects themselves should be passed by const-reference, and
 // stored by copy. They internally store their state via a refcounted class
 // and thus do not need to be deleted.
 //
 // The reason to pass via a const-reference is to avoid unnecessary
 // AddRef/Release pairs to the internal state.
 //
@@ skipping 219 matching lines @@
 //  - Performing compile-time asserts to avoid error-prone behavior
 //  - Returning an Callback<> with an arity matching the number of unbound
 //    parameters and that knows the correct refcounting semantics for the
 //    target object if we are binding a method.
 //
 // The Bind functions do the above using type-inference, and template
 // specializations.
 //
 // By default Bind() will store copies of all bound parameters, and attempt
 // to refcount a target object if the function being bound is a class method.
+// These copies are created even if the function takes parameters as const
+// references. (Binding to non-const references is forbidden, see bind.h.)
 //
 // To change this behavior, we introduce a set of argument wrappers
 // (e.g., Unretained(), and ConstRef()).  These are simple container templates
 // that are passed by value, and wrap a pointer to argument.  See the
 // file-level comment in base/bind_helpers.h for more info.
 //
 // These types are passed to the Unwrap() functions, and the MaybeRefcount()
 // functions respectively to modify the behavior of Bind().  The Unwrap()
 // and MaybeRefcount() functions change behavior by doing partial
 // specialization based on whether or not a parameter is a wrapper type.
@@ skipping 133 matching lines @@
 
 ]]  $$ for ARITY
 
 // Syntactic sugar to make Callbacks<void(void)> easier to declare since it
 // will be used in a lot of APIs with delayed execution.
 typedef Callback<void(void)> Closure;
 
 }  // namespace base
 
 #endif  // BASE_CALLBACK_H