In podcast 58, Joel encourages questions likes these as he wants SO to become THE place for answers, even if they have been answered in other places. This is a valid question, even though one could put it a little more polite.
– Ralph M. RickenbachJun 26 '09 at 5:30

5

@rahul I understand it's an old question. But I am sure even in 2009, SO expected the askers to put in some basic effort towards solving it. As it stands it doesn't show any effort at all. May be, that's why it was downvoted by many?
– P.P.Sep 12 '13 at 12:05

10

It's possible that the asker is not (or was not) fluent in English when writing this question
– MartinJan 16 '14 at 19:24

20

The question is polite, he just say what he wants. You are free to answer. No need for oversensible politness here.
– Markus SiebeneicherApr 24 '14 at 11:08

18

I think questions like these are great because it builds content for SO. IMO, who cares if the question doesn't have effort... the answers will have great content and that's what matters on this message board.
– Jwan622Oct 4 '14 at 22:42

I would also like to point out a very very easy to understand tutorial I just found. Arak's example is nice, but may be too short for someone who needs more examples (actually, comparing with other languages..). Take a look. It is important to understand this, as that keyword will lead us to understand lexical scope. howtonode.org/what-is-this
– CppLearnerAug 8 '11 at 6:13

6

This is a good answer. But the question is tagged with JavaScript. Therefore I think this shouldn't be marked as the accepted answer. Lexical scope specifically in JS is different
– BoyangOct 1 '16 at 10:29

3

Extremely good answer. Thank you. @Boyang I disagree. I'm not a Lisp coder, but found the Lisp example helpful, since it's an example of dynamic scoping, which you don't get in JS.
– dudewadOct 10 '16 at 20:36

2

Initially I thought the example was valid C code and was confused whether there was dynamic scoping in C. Perhaps the disclaimer at the end could be shifted to before the code example?
– Yangshun TayApr 8 '17 at 7:28

1

This is still a very helpful answer but I think @Boyang is correct. This answer refers to 'level', which is more along the lines of block scope that C has. JavaScript by default does not have block level scope, so inside a for loop is the typical problem. Lexical scope for JavaScript is only at the function level unless the ES6 let or const is used.
– icc97Apr 19 '18 at 11:44

The above code will return "I am just a local". It will not return "I am a global". Because the function func() counts where is was originally defined which is under the scope of function whatismyscope.

It will not bother from whatever it is being called(the global scope/from within another function even), that's why global scope value I am global will not be printed.

This is called lexical scoping where "functions are executed using the scope chain that was in effect when they were defined" - according to JavaScript Definition Guide.

Scope defines the area, where functions, variables and such are available. The availability of a variable for example is defined within its the context, let's say the function, file, or object, they are defined in. We usually call these local variables.

The lexical part means that you can derive the scope from reading the source code.

Lexical scope is also known as static scope.

Dynamic scope defines global variables that can be called or referenced from anywhere after being defined. Sometimes they are called global variables, even though global variables in most programmin languages are of lexical scope. This means, it can be derived from reading the code that the variable is available in this context. Maybe one has to follow a uses or includes clause to find the instatiation or definition, but the code/compiler knows about the variable in this place.

In dynamic scoping, by contrast, you search in the local function first, then you search in the function that called the local function, then you search in the function that called that function, and so on, up the call stack. "Dynamic" refers to change, in that the call stack can be different every time a given function is called, and so the function might hit different variables depending on where it is called from. (see here)

unit Main;
uses aUnit; // makes available all variables in interface section of aUnit
interface
var aGlobal: string; // global in the scope of all units that use Main;
type
TmyClass = class
strict private aPrivateVar: Integer; // only known by objects of this class type
// lexical: within class definition,
// reserved word private
public aPublicVar: double; // known to everyboday that has access to a
// object of this class type
end;
implementation
var aLocalGlobal: string; // known to all functions following
// the definition in this unit
end.

The closest Delphi gets to dynamic scope is the RegisterClass()/GetClass() function pair. For its use see here.

Let's say that the time RegisterClass([TmyClass]) is called to register a certain class cannot be predicted by reading the code (it gets called in a button click method called by the user), code calling GetClass('TmyClass') will get a result or not. The call to RegisterClass() does not have to be in the lexical scope of the unit using GetClass();

Another possibility for dynamic scope are anonymous methods (closures) in Delphi 2009, as they know the variables of their calling function. It does not follow the calling path from there recursively and therefore is not fully dynamic.

Lexical (AKA static) scoping refers to determining a variable's scope based solely on its position within the textual corpus of code. A variable always refers to its top-level environment. It's good to understand it in relation to dynamic scope.

The portion of a program or segment unit in which a declaration
applies. An identifier declared in a routine is known within that
routine and within all nested routines. If a nested routine declares
an item with the same name, the outer item is not available in the
nested routine.

Lexical scoping: Variables declared outside of a function are global variables and are visible everywhere in a JavaScript program. Variables declared inside a function have function scope and are visible only to code that appears inside that function.

There is an important part of the conversation surrounding Lexical and Dynamic Scoping that is missing: a plain explanation of the lifetime of the scoped variable - or when the variable can be accessed.

Dynamic scoping only very loosely corresponds to "global" scoping in the way that we traditionally think about it (the reason I bring up the comparison between the two is that it has already been mentioned - and I don't particularly like the linked article's explanation); it is probably best we don't make the comparison between global and dynamic - though supposedly, according to the linked article, "...[it] is useful as a substitute for globally scoped variables."

So, in plain English, what's the important distinction between the two scoping mechanisms?

Lexical scoping has been defined very well throughout the answers above: lexically scoped variables are available - or, accessible - at the local level of the function in which it was defined.

However - as it is not the focus of the OP - dynamic scoping has not received a great deal of attention and the attention it has received means it probably needs a bit more (that's not a criticism of other answers, but rather a "oh, that answer made we wish there was a bit more"). So, here's a little bit more:

Dynamic scoping means that a variable is accessible to the larger program during the lifetime of the function call - or, while the function is executing. Really, Wikipedia actually does a nice job with the explanation of the difference between the two. So as not to obfuscate it, here is the text that describes dynamic scoping:

...[I]n dynamic scoping (or dynamic scope), if a variable name's scope is a
certain function, then its scope is the time-period during which the
function is executing: while the function is running, the variable
name exists, and is bound to its variable, but after the function
returns, the variable name does not exist.

A lexical scope in Javascript means that a variable defined outside a function can be accessible inside another function defined after the variable declaration. But the opposite is not true, the variables defined inside a function will not be accessible outside that function.

This concept is heavily used in closures in Javascript.

Let say we have the below code.

var x = 2;
var add = function() {
var y = 1;
return x + y;
};

Now, when you call add() --> this will print 3.

So, add() function is accessing the global variable x which is defined before method function add. This is called due to lexical scoping in javascript.

Here's a different angle on this question that we can get by taking a step back and looking at the role of scoping in the larger framework of interpretation (running a program). In other words, imagine that you were building an interpreter (or compiler) for a language and were responsible for computing the output, given a program and some input to it.

Interpretation involves keeping track of three things:

1) State - namely, variables and referenced memory locations on the heap and stack.

2) Operations on that state - namely, every line of code in your program

3) The Environment in which a given Operation runs - namely, the projection of State on an Operation.

An interpreter starts at the first line of code in a program, computes its environment, runs the line in that environment and captures its effect on the program's state. It then follows the program's control flow to execute the next line of code, and repeats the process till the program ends.

The way you compute the environment for any operation is through a formal set of rules defined by the programming language. The term "binding" is frequently used to describe the mapping of the overall state of the program to a value in the environment. Note that by "overall state" we do not mean global state, but rather the sum total of every reachable definition, at any point in the execution)

This is the framework in which the scoping problem is defined. Now to the next part of what our options are.

As the implementor of the interpreter, you could simplify your task by making the environment as close as possible to the program's state. Accordingly, the environment of a line of code would simply be defined by environment of the previous line of code with the effects of that operation applied to it, regardless of whether the previous line was an assignment, a function call, return from a function, or a control structure such as a while loop.

This is the gist of dynamic scoping, wherein the environment that any code runs in is bound to the state of the program as defined by its execution context.

Or, you could think of a programmer using your language and simplify his or her task of keeping track of the values a variable can take. There are way too many paths and too much complexity involved in reasoning about the outcome the totality of past execution. Lexical Scoping helps do this by restricting the current environment to the portion of state defined in the current block, function or other unit of scope, and its parent (i.e. the block enclosing the current clock, or the function that called the present function).

In other words, with Lexical Scope the environment that any code sees is bound to state associated with a scope defined explicitly in the language, such as a block or a function.

Lexical Scope means that in a nested group of functions, the inner
functions have access to the variables and other resources of their
parent scope. This means that the child functions are lexically bound
to the execution context of their parents. Lexical scope is sometimes
also referred to as Static Scope.

The thing you will notice about lexical scope is that it works
forward, meaning name can be accessed by its children's execution
contexts. But it doesn't work backward to its parents, meaning that
the variable likes cannot be accessed by its parents. This also tells
us that variables having the same name in different execution contexts
gain precedence from top to bottom of the execution stack. A variable,
having a name similar to another variable, in the innermost function
(topmost context of the execution stack) will have higher precedence.

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).