From c2:

Each time TWO-FUNS is called, each lambda expression is evaluated to produce a closure. The two closures are returned as a list of two elements. A different lexical environment is in effect each time, in which the name X is bound to a value. The two closures share the binding of X. However, each call to TWO-FUNS results in a new lexical environment, so that the binding of X used by the closures in FUNS1 is distinct from the bindings of X used by the closures in FUNS2.

From Wikipedia:

The scope of the variable encompasses only the closed-over function, so it cannot be accessed from other program code.

From UCSD:

An important part of closure is that when we say that the set is "closed under" an operation, it has to be true for everything in the set. So even if all kinds of candies–except for one–were still candy after the bird() operation, Candy would still not be closed under bird(). Next is an example of closure that is more formal.

These strike me as serving as potential counterarguments to what you seem to be trying to say.

In any case, your argument seems to be "None of these pages I've picked out explicitly contradicts me, so I'm right!" I don't find that a convincing argument.

Here's a bunch of definitions (you can Google for more) that all say the exact same thing:
http://c2.com/cgi/wiki?LexicalClosure
http://www.jibbering.com/faq/faq_notes/closures.html
http://www.learnthat.com/define/view.asp?id=3938
http://en.wikipedia.org/wiki/Closure_(computer_science);

Or if you're more inclined, you might want to imagine how this came about from closures in algebra:
http://www.cs.ucsd.edu/~clbailey/ClosureOverview.htm

I don't because it doesn't matter.

So — you're saying closures are the exact same thing as a first-class function in a language with global scope. The mind boggles.

Actually, the anonymous function doesn't have access to the larger scope. It only has access to variable bindings that existed there when it closed over it.

Thanks for pedantically missing my point.

What happens in the larger scope afterwards is none of its business:

Maybe so — but you have yet to suggest a situation where the parent scope staying open isn't identical to just using variables with global scope, for purposes of a hypothetical closure.

x = 1
lambda { x = 2; y = 3 }.call
puts x
puts y rescue puts 'no y'
y = 4
puts y

When you use a block, it creates an anonymous function and closes over the enclosing scope. That's the closure.

I don't see how "closes over the enclosing scope" has any meaning other than "I'm trying to come up with a way to sound credible when I suggest that the parent scope doesn't have to close to create a closure." The nested scope doesn't "close over" its context. It exists within its context, and can access it if that context is lexical or global. If it's lexical, and the parent scope closes, the nested scope still has access to that context — unless the nested scope no longer exists. It's almost tautological.

It allows the other scope to die, and the closure to still access those bound variables, but it doesn't require the other scope to ever die.

If the parent scope doesn't die, it's not a closure — it's a nested function (or local linguistic equivalent of a function, for the pedants in the audience).

Otherwise, you're just talking about what global and lexical scope have in common.

I suppose one might conceivably suggest that a closure could exist without the parent scope having closed, in some hypothetical language where a function can have a return value without closing, but as far as I'm aware such a language doesn't exist.

What about the case where the parent scope doesn't close? In such a case, the block does not get its context closed around it, and doesn't become a closure.