dynamic scope vs lexical scope


On Feb 24, 12:35 pm, "J. Winter" 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)


• What are OOP's Jargons and Complexities

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.

∑ http://xahlee.org/

On Feb 24, 1:12 pm, Kaz Kylheku wrote:
> On 2009-02-24, J. Winter wrote:
> > Is there anything really important to loose if you use only lexical
> > scope such as in scheme.
> There is something important lost if the programming language only supports
> lexical scope.
> You don't lose anything by only using lexical scope, if lexical scope solves
> your problem, and lends an adequate expressiveness to your solution.
> Dynamic scope gives us an alternate way to invisibly pass an indefinite number
> of parameters to a function

what a idiocracy.

i do wonder, if any reputable computer scientist would blub out such idiotic things as this thread's lispers have been.

Let me give a lucid account on the gist of dynamic scope and lexical scope.

Dynamic scope, is when computers are still slow (1960s, 1970s), there's no such thing as so-called “computer science” yet, and mathematicians at the time have little idea what they are doing on the computers.

When after a few decades, mathematicians got some whiff of the math of computer languages, lexical was born. But by this time, mathematicians have gone. What's left are so called computer scientist, typically morons.

From a mathematical and practical perspective, everything about dynamic scope is just global vars. Like closure, there's nothing useful these things add from practical software developement perspective.

∑ http://xahlee.org/


No comments:

Post a Comment