How to understand this form (something) (param);

[John G Harris]

Could you please refer to the proper section for our better understanding?
That applies to your previous reply as well.

It's the note in ECMA 262, section 13.1.2.

John

 

[John G Harris]

This is, of course, an arguable position, even a purely philosophical
position. If all the structures and mechanisms that facilitate
closures are in place why shouldn't a closure be considered to exists?
The same goes for the case where you preserve the inner function but
do not employ its environment (no other inner functions, formal
parameters or variables (or no uses of any of them in the inner
function)); if there is no way to determine whether the environment
was preserved (so no consequences either way) is it worth labelling it
a closure just because the necessary mechanism and structures may be
in place?

<snip>

I think it's a terminology problem. We need two names for two different
things :

A proper closure occurs when an inner function is made callable from
outside its outer function, *and* the code of the inner function
accesses parameters or local variables of its outer function(s). The
standard requires this to work as in a traditional closure. There are no
options about this.

An empty closure occurs when an inner function is made callable from
outside its outer function, *and* the code of the inner function
accesses none of the parameters and local variables of its outer
function(s), *and* the inner function still carries the closure
machinery with it. The standard makes this an option. It can affect
performance and garbage collection, but this is (officially) not
observable behaviour of the program.

If, instead, the inner function does not carry the closure mechanism
with it then it is not a closure. The standard makes this an option as
well.

Incidentally, since Jorge has mentioned it, if inner functions cannot be
made callable from outside then there are no closures, only lexical
scopes. (As in Pascal).

John

 

[Jorge]

On Thu, 6 Aug 2009 at 05:10:39, in comp.lang.javascript, Richard

Cornford wrote:



  <snip>

I think it's a terminology problem. We need two names for two different
things :

A proper closure occurs when an inner function is made callable from
outside its outer function, *and* the code of the inner function
accesses parameters or local variables of its outer function(s). The
standard requires this to work as in a traditional closure. There are no
options about this.

An empty closure occurs when an inner function is made callable from
outside its outer function, *and* the code of the inner function
accesses none of the parameters and local variables of its outer
function(s), *and* the inner function still carries the closure
machinery with it. The standard makes this an option. It can affect
performance and garbage collection, but this is (officially) not
observable behaviour of the program.

If, instead, the inner function does not carry the closure mechanism
with it then it is not a closure. The standard makes this an option as
well.

Incidentally, since Jorge has mentioned it, if inner functions cannot be
made callable from outside then there are no closures, only lexical
scopes. (As in Pascal).

1.- Contexts must be created, setup and inserted in the scope chain in
any case (the mechanism of identifier resolution in accordance with
the scoping rules).

2.- Sometimes a function's context can't be destroyed upon exiting the
function : when at that point in time there still exists yet another
function whose context points to, includes, has access to, uses it:
that is necessarily the context of an outliving inner function. It's
then that we say that a closure has been created.

3.- There's no "closure machinery". A closure is the absence of
destruction of a context.

 

[RobG]

On Aug 6, 5:05 am, kangax wrote:

Yes.


Yes.

<snip>

I am not sure that that last sentence should be included. This is one
place where John G Harris' "scoping rule !== closure" comes in.

I think that is exactly the point that it moves from "scoping rule" to
closure, i.e. it is at the moment that it is available externally that
it becomes a closure.

Consider a programming language that is exactly like ECMAScript in
every respect except that the named properties of activation/variable
objects that are created during variable instantiation are deleted as
execution contexts are returned from. This is then a language in which
closures don't exist, yet the behaviour of an inner function called
(even very indirectly) before the function that contains it (within
which it was created) returns is identical to what it would be in
ECMAScript. That behaviour is explained by the language's scoping
rules alone and doesn't require closures.

Sure, but all we learn from that is that a closure creating function
acts like a typical function if the closure isn't used. If a function
is declared but never used, is it still a function?

For a closure I think you want to see both a function object _and_ its
environment outliving their normal (minimum, given the uncertain
nature of garbage collection) lifespan.

This is, of course, an arguable position, even a purely philosophical
position. If all the structures and mechanisms that facilitate
closures are in place why shouldn't a closure be considered to exists?

I think it should.

The same goes for the case where you preserve the inner function but
do not employ its environment (no other inner functions, formal
parameters or variables (or no uses of any of them in the inner
function)); if there is no way to determine whether the environment
was preserved (so no consequences either way) is it worth labelling it
a closure just because the necessary mechanism and structures may be
in place?

Yes - if I buy a shovel but leave it in the shed and never use it,
it's still a shovel. There may later arise some unexpected consequence
due to the existence of the closure - does it suddenly exist because
it now has some measureable effect?

Earlier someone mentioned the question of whether if tree falls in a
forest, does it still makes a sound if there is nobody around to
perceive it. A pragmatic attitude might suggest that if you have no
way of knowing if/when a tree falls there is little point in expending
any effort worrying about how much noise it may make if it did.

Just because a particular person didn't hear it doesn't mean that no
one did. If a closure is created, how can anyone be *certain* that it
isn't used? How can it be known with certainty that there are no
unintended consequences, say for performance or memory consumption?
That no as yet unseen code will be added to the page? Or the closure
has been assigned to some other identifier and is called in some
obscure fashion?

Hopefully you're playing devil's advocate here. Closures have been
shown to have (hopefully unintentional) adverse consequences in some
circumstances (e.g. IE circular references and memory leaks). I think
the broader definition suits if for no other reason than it causes
programmers to be more aware of the possible consequences of their
code.

 

[Lasse Reichstein Nielsen]

1.- Contexts must be created, setup and inserted in the scope chain in
any case (the mechanism of identifier resolution in accordance with
the scoping rules).

That's the specification. Implementations may optimize as they see
fit, as long as it's semantically equivalent.
If you have a good escape analysis, you could put variables on the
stack and not create an actual scope/context object, but ofcourse
it would be equivalent.
(Not that I'm aware of anybody doing that in Javascript).

2.- Sometimes a function's context can't be destroyed upon exiting the
function : when at that point in time there still exists yet another
function whose context points to, includes, has access to, uses it:
that is necessarily the context of an outliving inner function. It's
then that we say that a closure has been created.

That's one way of viewing it. It's not mine, though.

Another definition is to say that a closure is:
A piece of program code together with bindings of its free variables.
No more, no less.

Function objects are closures. They combine code and binding of the
free variables of the code (specified as remembering the entire scope
chain, but that need not be necessary).

That binding might be trivial, if the code has no free variables. You
can argue that it isn't really a closure then, but that's not really
important.

3.- There's no "closure machinery". A closure is the absence of
destruction of a context.

Closures as "capturing static scope" can be detected even inside their
scope/context, since they are not affected by shadowing of their free
variables' definitions:

function test(a, b) {
function add(x) { return a + x; }
function doit(a, b) { return add(b); }
return doit(42, b);
}
test(37,5); // evaluates to 42.

In lisp, which doesn't have closures, but instead has dynamic scope,
the result would have been 47.


/L

 

[John G Harris]

That binding might be trivial, if the code has no free variables. You
can argue that it isn't really a closure then, but that's not really
important.

<snip>

It can be important if the delayed garbage collection has embarrassing
consequences, especially if some browsers can go wrong and others can't.
It's then that you need two names for the two cases, otherwise you can't
talk about them sensibly.

John