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

base/callback.h

 // This file was GENERATED by command:
 //     pump.py callback.h.pump
 // DO NOT EDIT BY HAND!!!
 
 
 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef BASE_CALLBACK_H_
 #define BASE_CALLBACK_H_
 
 #include "base/callback_forward.h"
 #include "base/callback_internal.h"
 #include "base/template_util.h"
 
 // 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 220 matching lines @@
 //  - 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)
+// 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 467 matching lines @@
 };
 
 
 // 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