«

On Feb 24, 12:35 pm, "J. Winter" <jwi@dlc_NO_SPAM_.fi.invalid> wrote:
> Is there anything really important to loose if you use only lexical
> scope such as in scheme. (I've been learning CL again after twenty years.)

the short answer is, no.

tech geekers make a lot fuzz about scope. In general, the more
smattering knowledge they have about compilers, the more stupid their
opinion becomes about languages.

For a explication of scope monster, see the section:
The Rise of “Access Specifiers” (or, the Scoping Complexity of OOP)

in

• What are OOP's Jargons and Complexities
http://xahlee.org/Periodic_dosage_dir/t2/oop.html

Here's a plain text excerpt:

---------------------------------------------

The Rise of “Access Specifiers” (or, the Scoping Complexity of OOP)

In programing, a variable has a scope — meaning where the variable can
be seen. Normally, there are two basic models: dynamically scoped and
lexically scoped. Dynamic scoping is basically a time based system,
while lexical scoping is text based (like “what you see is what you
get”). For example, consider the following code:

subroutine f() {return y}
{y=3; print f();}

In dynamic scoping, the printed result is 3, because during evaluation
of the block all values of y is set to 3. In lexical scoping, a
undefined “y” is printed because the two “y” in the code are
considered different because they are in separate blocks of curly
brackets. With regards to language implementation, Dynamic Scoping is
the no-brainer of the two, and is the model used in earlier languages.
Most of the time, lexical scoping is more natural and desired because
it corresponds to the code as it appears.

Scoping is also applicable to subroutines. That is to say, where
subroutines can be seen. A subroutine's scope is usually at the level
of source file (or a concept of a module/package/library), because
subroutines are often used in the top level of a source file, as
opposed to inside a code block like variables.

In general, the complexity of scoping is really just how deeply nested
a name appears. For example see in the following code:

name1; // top level names. Usually subroutines, or global
variables.
{
name2 // second level names. Usually variables inside
subroutines.
{
name3 // deeper level names. Less often used in structured
programing.
// sometimes used in nested loops
}
}

If a programing language uses only one single file of commands in
sequence as in the early languages such as BASIC, there would be no
scoping concept. The whole program is of one single scope.

OOP has created a immense scoping complexity because its mode of
computing is calling nested subroutines (methods) inside subroutines
(classes). We detail some aspects in the following.

In OOP, variables inside subroutines (class variables) can also be
accessed thru a reference the subroutine is assigned to (that is, a
object). In OOP parlance: a variable in a class has a scope, while the
same variable when the class is instantiated (a objet) is a different
scoping issue. In other words, OOP created a new entity “variable thru
reference” that comes with its own scoping issue. For example:

class a_surface() {
coordinates={...}; // a variable
...
}

class main {
mySurface = new a_surface();
mySurface.coordinates = {...}; // accessing the “same” variable
}

In the above code, the variable “coordinates” appears in two places.
Once as defined inside a_surface, and once as a instantiated version
of a_surface (a object). The variable as thru the object reference
apparently has a entirely different scoping issue than the same
variable inside the subroutine (class) definition. The question for
OOP language designers is: what should the scope be for variables
referred thru objects? Lexically within the class the object is
created? Lexically within the class the variable is defined??
globally? (and what about inherited classes? (we will cover OOP
inheritance later))

As we've seen, methods are just inner-subroutines, and creating
objects to call methods is OOP's paradigm. In this way, names at the
second-level programing structure often associated with variables (and
inner-subroutines), is now brought to the forefront. This is to say,
the scoping of subroutines are raised to a level of complexity as the
scoping of variables. (they are now both in the 2nd level of names (or
deeper).)

Further: In a class definition, variables are lexically scoped. But
the ability for a object to refer/change a class variable is
essentially a model of dynamic scope. Thus, OOP created a complexity
of mixing these 2 scoping models.

All in all, the scoping complexities of OOP as applied to different
OOP entities (classes, class variables, class's methods, object
variables and methods) is manifested as access specifiers in Java. In
Java, access specifiers are keywords “private”, “protected”, “public”,
used to declare the scope of a entity. Together with a default scope
of no-declaration, they create 4 types of scope, and each of these
keywords has entirely different effects depending whether they are
used on a variable, a method, a constructor, or a class.

See this tutorial of Java's access specifiers for detail: Java's
Access Specifiers.


Xah
∑ http://xahlee.org/

☄