So, at what stage the creation of the function is performed. Code parsing?

As mentioned in ES3.Ch5, functions are divided into function declarations (FD) and function expressions (FE). The time when each of a function type is created differs, but still, it’s not parsing stage.

At parsing stage only the parsing itself is applied, that is — ES concrete syntax is transformed into the abstract syntax tree (AST). At this stage, the parser already determined that it has functions in some positions (and even their types, FD, FE). But runtime is not activated at this stage yet.

And only after that, when the code is executed, then already the interpretation of the parsed AST is started. Here already we enter different execution contexts. And exactly on entering the context stage (but before its actual code execution) the interpreter creates all FDs. And only when it starts to execute the code (the second stage of context handling) all FEs are created.

So the answer is — no, not at parsing stage, but at runtime context handling stage, which is divided on two stages as well: the entering (FDs are created) and execution (FEs are created).

Anyways, I have a question. In all your articles you mention that the [[Scope]] variable is saved and does not change after creation. So, at what stage the creation of the function is performed. Code parsing?

Thanks.

we can say the function a create a “a closure”,but running the a function
dosen’t use the closure technology.

You used a practical definition of closures. However, as it was mentioned, theoretically in ECMAScript all functions are closures. Because for all functions at their creation a parent scope chain is saved (this saved scope chain is stored in the [[Scope]] property of functions). I.e. a function possibly won’t be even activated, but the [[Scope]] is already saved at creation.

A normal global function if uses some global variable is also a closure (though, it’s not so obvious until we won’t have an ambiguous case):

var foo = 10;

function bar() {
  console.log(foo);
}

bar(); // 10

Interesting? Not so (because it’s just an access to the global variable). However, if we pass the same “bar” function as a “funarg”, we see the closure nature (i.e. statically saved parent scope chain — in which “bar” is created, but not when it’s executed):

var foo = 10;

function bar() {
  console.log(foo);
}

function bar(funArg) {
  // local "foo"
  var foo = 20;
  funArg(); // 10 (closured), but not 20
}

baz(bar); // 10

If a function doesn’t use free variables (as in your example with “a” function), there may be a case with e.g. third-level inner function which does use free variables.

(function foo() {

  // a variable of the
  // "foo" function context
  var x = 10;

  // function "bar" does not
  // use free variables. Should it
  // save parent (i.e. "foo"'s) scope
  // chain and be a closure?

  (function bar() {

    // however, "bar" has another inner
    // function "baz" which uses "x" of "foo"

    (function baz() {
      console.log(x); // 10
    })();  

  })();

})();

And since a [[Scope]] is saved at creation, “bar” should save scope chain of “foo” anyway. Because when “baz” is created (at “bar” activation), it takes scope chain of the context in which it is created. And it’s created in the “bar”. More exactly this case may be seen, if first to return “bar” to the outside, when context of “foo” will be already destroyed.

However, in real practice, if there is some completely safe case (as again with your “a” function), I think implementations may do some optimization and do not save parent’s scope chain and to used even stack but not “heap” (as I wrote in the article). But, it’s already an implementation level and is not described in the ECMA-262. Also more complex parsing rules are needed.

dose this code use the closure technology?

Possibly I used not so good example. However, yes, it’s may be (even in practice) also a closure (in theory, repeat, it is a closure anyway). For example (abstractly, not regarding particular implementation in ECMAScript), sort method may be deffered, i.e. activated after some time delay. Thus, if a sort-funarg uses some free variable from parent context, it should be a closure. Or, e.g. a sort-funarg simply may be passed as other function with also free variables:

var someFreeVariable = true;

function sortFn(a, b) {
  if (someFreeVariable) {
    return a < b ? 0 : 1;
  }
  return -1;
}

(function foo() {

  // another variable with
  // the same name
  var someFreeVariable = false;

  // however, sort uses "sortFn"
  // with "someFreeVariable" == true
  return [1, 2, 3].sort(sortFn);

})();

Dmitry.

function a(){
    var b='';
    alert(b);
}

we can say the function a create a “a closure”,but running the a function
dosen’t use the closure technology.

* exist even if context in which they were created is already finished (e.g. are the functional values returned from function);
* reference in a code to free variables.

if one code which meets one of the condition above,we can say the code use the closure technology.

but if i am correct,in your articel

Practical usage of closures

[1, 2, 3].sort(function (a, b) {
  ... // sort conditions
});

dose this code use the closure technology?

“a closured lexical context” is the execution context?

Nope, a “closured context” here means a term mostly from the general theory. Regarding ECMAScript it means a “parent variable object” and, more closer, a complete “parent scope chain”. I think I should correct terminology used in this article to better conform ES terminology.

if i am wrong,can you explain for me? thanks

You are correct. However, it’s not a whole context (scope chain, variable object, this value) is saved, but only context’s scope chain (as you know a this value in contrast with other languages, e.g. Ruby or Python, isn’t captured into the closure).

Dmitry.

Therefore, in this case as a rule, a closured lexical context is stored in the dynamic memory allocation (“heap”, so-called heap-based implementations), with using the garbage collector (GC) and references counting.

“a closured lexical context” is the execution context?

(function(){
    var a=0;
    var b=1;
    var c=2;
    ....

    function test(){ alert(a) }
    return test;
})()

i use the program above to avoid the variables conflict.

when the anonymous function finish,the variable a still can be accessed.
this is because the global object refers the test function,
and the test function refers the anonymous function’s execution context so the anonymous function’s execution context wont’t be GC.

if i am wrong,can you explain for me? thanks

for example, in Ruby programming language, as a closure a procedure object, a lambda-expression or a code block can be used

I didn’t understand completely this sentence.Can you give me a detailed explanation? thank you!

There I just explain that in Ruby there are several ways to create a closure — to show, that a closure isn’t required to be exactly a function:

a = 10

def foo(&code_block)
  a = 20
  code_block.call # 10 (statically closured), but not 20
end

# lambda - is a closure
closure = lambda { print(a) }
foo(&closure) # 10

# Proc.new - is also a closure
also_closure = Proc.new { print(a) }
foo(&also_closure) # 10

# simple code block - {} or do/end
# is also a closure
foo { print(a) } # 10

Every of described approaches has its own features — e.g. some created callable object checks quantity of passed parameters, some — does not, or differently handles return statement. Besides there are other ways to create a closure in Ruby, e.g. to use method function applied for some method — you can find details in documentation for Ruby.

But my the main idea was to show, that a closure concept isn’t requited to be related exactly with a function concept. Although, in ECMAScript it is so.

Dmitry.

for example, in Ruby programming language, as a closure a procedure object, a lambda-expression or a code block can be used

I didn’t understand completely this sentence.Can you give me a detailed explanation? thank you!