[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Lexical scope definition
- From: "Jonathan Branam" <sspeare@...>
- Date: Wed, 29 Aug 2001 10:20:50 -0700
I should probably stay out of this, but it is too tempting. Unfortunately I
don't know what book is considered the "Bible of Programming Languages" or I
would check it. However, I have always heard lexical scope definied the same
way (until now).
Lexical scope: The scope of an identifier can be determined by a lexical
analysis of the block of code.
Normally this description is also followed by other statements such as: This
can be determined at compile time and is therefore more efficient. This
constrasts with dynamic scoping in which the the scope of an identifier can
only be determined at run-time.
PS: I do not claim that the internet is a good place to go for information
of this kind, as it contains lots of misinformation as well. But at least it
usually gives you a sense of what the "popular" opinion is. In any case,
almost every reference I found supports this definition. However, several do
attempt to add more to it. Such as the requirement that identifier scope can
reach up through the function tree (I mean, that you can access identifiers
from enclosing functions always).
lexical scope n. scope that is limited to a spatial or textual region within
the establishing form. ``The names of parameters to a function normally are
<programming> (Or "static scope") In a lexically scoped language, the scope
of an identifier is fixed at compile-time to be the smallest block
(begin/end or function/procedure body) containing the identifier's
declaration. This means that an identifier declared in some block is only
accessible within that block and from procedures declared within it.
Opposite of dynamic scope. See activation record.
Scheme uses a lexical scope rule. (We can also say that Scheme is statically
scoped, rather than dynamically scoped, like some old Lisps.) When you see a
variable name in the code, you can tell what variable it refers just to by
looking at the source code for the program. A program consists of possibly
nested blocks of code, and the meaning of the name is determined by which
variable binding constructs it's used inside.
Static (Lexical) Scope
Based on program text
To connect a name reference to a variable, you (or the compiler) must find
Search process: search declarations, first locally, then in increasingly
larger enclosing scopes, until one is found for the given name
Enclosing static scopes (to a specific scope) are called its static
ancestors; the nearest static ancestor is called a static parent
Lexical scope. Here references to the established entity can occur only
within certain program portions that are lexically (that is, textually)
contained within the establishing construct. Typically the construct will
have a part designated the body, and the scope of all entities established
will be (or include) the body.
Example: the names of parameters to a function normally are lexically
What is lexical scope?
my variables are said to have lexical scope, which means that variables are
defined for the block they are in, and they are not generally visible to
subroutines. There are exceptions, and I'll tell you about those later in
this feature. To use my, simply put it in front of your variable name when
you declare it, like this:
Perl will create space for a private variable named $variable, visible only
within the block of code that defines it. The variable is used while within
the block, and Perl gets rid of it when its done with the block.