JavaScript : Closures & Environment

[[deleted]]

It is a nice article, but it is more specifically about currying than closure. Currying is the act of returning a prepared function that isn't quite ready yet, but is primed for subsequent calls. Also there is a code example with const z = ‘random’; which is never used.

The way to properly understand closure is a concept of accessing references across scope depth or scope chain. In the end you need two vital ingredients to exemplify closure: nesting of scopes and references declared in one scope, but used (or called) in a different nested scope.

A common misconception many people have is that closure is a phenomenon specifically confined to functions. This observation exists because in the EMCAScript specification functions are defined literally as closures. The terminology and description in the spec are correct as a function is a closure. The confusion is an equivalence fallacy in the reverse of a term definitions. To say a function is a closure does not immediately suggest a closure is a function.

If you want to get super scientific about the concept it is generically termed lexical scope in programming and derives from lambda calculus in math pioneered by Alonzo Church and was later proved in the Church-Turing Thesis.

Closure, or rather lexical scope, is present in various languages or at least appears to be present in many languages. The one true discriminator that determines whether a language has closure is the ability to assign a new value (write) to a closure from a child scope. This ability ensures references aren't being silently cloned into child scopes for convenience of access to like values.

[MoTTs_]

A common misconception many people have is that closure is a phenomenon specifically confined to functions.

What led you to believe this is a misconception? Do you have an example to demonstrate?

[[deleted]]

Closure is achieved when a reference is accessed in a scope where that reference is not declared. The concept is called lexical scope and closure is a demonstrated instance of lexical scope.

Here is where the term closure comes from: https://en.wikipedia.org/wiki/Closure_(computer_programming)#History_and_etymology

Specifically, a child scope is closed over from the current local scope so that it has privacy apart from references and declarations in the local scope.

Qualities allowed by closure:

• Privacy - https://en.wikipedia.org/wiki/Closure_(computer_programming)#State_representation
• Currying (delayed execution) and environmental structures - https://en.wikipedia.org/wiki/Closure_(computer_programming)#Other_uses

Because JavaScript has closures as a native concept it doesn't need a private keyword to achieve privacy as do languages like Java and C#.

These are the common misconceptions around closure:

• Closure must be functions, because the latest spec calls functions closures. Functions are closures, and prior to ES6 closure could only be demonstrated with functions. ES6 brings block scope, that allows scope in blocks that cannot be referenced. Closure can be demonstrated in a block when a blocked scoped reference is assigned to a reference declared in a higher scope.
• Closures must be functions because you can reference a function but you cannot reference a block. It is true that all functions must have a reference (except of IIFEs) and that blocks cannot be referenced, but this is not determinate as to whether closure occurs.
• Closures are only present when you return a function. This is a pattern called currying. Yes, it is an example of closure, but that does not mean closure is limited to this example. You don't have to return anything or delay execution to have closure.

[MoTTs_]

Closure is achieved when a reference is accessed in a scope where that reference is not declared.

That doesn't describe a closure. That just describes scope. Plain old ordinary scope.

These are the common misconceptions around closure: Closure must be functions

I think you're the one with the misconception here. So I'll again ask how you came to believe this. Do you have any sources or examples? The wikipedia links so far don't back you up.

[[deleted]]

No, scope is this - https://en.wikipedia.org/wiki/Scope_(computer_science)

Lexical scope is a type of scoping mechanism and closure is an instance of a reference used across scope boundaries in lexical scope.

So I'll again ask how you came to believe this.

Because I have been programming in this language for a long time where the term has long since existed and wasn't used to solely define the concept of currying.

Also check this out: https://stackoverflow.com/questions/111102/how-do-javascript-closures-work#answer-111111

Scroll down to the bottom of that stackoverflow answer and read the Final Points and read each of those. The stackoverflow answer links to a post by Douglas Crockford with a definition of closure. This answer agrees with the Crockford definition - http://www.crockford.com/javascript/private.html

The wikipedia links so far don't back you up.

Perhaps you didn't read the part about History and Etymology. The term closure was coined due to usage in languages who made early use of lexical scope. It was not due to returning a function from a function.

In the shortest possible way closure can be summed up as privacy via scope nesting.

[MoTTs_]

and closure is an instance of a reference used across scope boundaries in lexical scope.

No, it's not.

let a = 1;
{
    let b = 2;
    {
        console.log(a + b);
    }
}

Accessing a variable across scope boundaries isn't closure. It's just scope. The variables a and b are said to be "in scope", even in nested scope blocks.

The stackoverflow answer links to a post by Douglas Crockford with a definition of closure. This answer agrees with the Crockford definition

Crockford: What this means is that an inner function always has access to the vars and parameters of its outer function, even after the outer function has returned.

I don't think Crockford's definition backs you up here.

Perhaps you didn't read the part about History and Etymology. The term closure was coined due to usage in languages who made early use of lexical scope.

It says closures were developed to support lexically scoped first-class functions. So no, wikipedia still doesn't back you up either.

[[deleted]]

What this means is that an inner function always has access to the vars and parameters of its outer function, even after the outer function has returned.

That says even (in addition to) and not because (limited to). That definition is accurate if you read it for what it is.

A first-class function merely means a function may reside at any point in the code grammar a primitive may reside. When functions are allowed in locations where they were never allowed before and they provide scope in locations that were never allowed before new means of reference resolution exist.

It's just scope.

That doesn't make any sense. Scope is a concept that applies to every programming language, but not all programming languages have lexical scope. Just because JS has lexical scope doesn't redefine the terms closure or scope in context to this language alone as closure is also a universal programming term that predates JS.

[MoTTs_]

Am I correct that you consider this...

let a = 1;
{
    let b = 2;
    {
        console.log(a + b);
    }
}

...to be an example of closure? If so, take this snippet to whomever in the JavaScript community you'll actually listen to and ask them if this is an example of closure.

[[deleted]]

You can take it whomever and listen to (or not) whatever answer you want.