Talk:Scope (computer science)

Misleading lead text.

In my experience, the concept of "scope" pertains exclusively to identifiers and declarations; and indeed, most of the article is only about scope insofar as it pertains to identifiers and declarations. (Though, maybe that's not saying much: most of the article is only about variable-names, and obviously lots of other things can also have scope.) The lead text, however, seems to downplay that aspect of scope; the word "identifier" hardly appears, and instead we get text about "values and expressions", and about how scopes can "contain statements and/or expressions which define an executable algorithm or part thereof" and can "nest or be nested" (which I think are really supposed to be statements about blocks, in block-structured languages, rather than about scopes per se).

So, I think the lead text should be completely rewritten.

Before I proceed — does anyone disagree?

—Ruakh_TALK 04:36, 1 February 2012 (UTC)

 Done —Ruakh_TALK 15:20, 2 February 2012 (UTC)

"variables in C can be accessed outside their scope"

Diego Moya (talk · contribs) removed the statement that

> Outside of its scope, a declaration or identifier effectively does not exist.

describing it as a "false claim" because "variables in C can be accessed outside their scope".

I think (s)he's mistaken, but edit-summaries aren't the place to carry out this argument, so: Diego Moya, can you explain what you mean? For example, can you give an example of valid C code where a variable-name is accessed outside of its scope?

—Ruakh_TALK 16:12, 23 February 2012 (UTC)

As I further edited, some compilers in some languages allow the programmer to access the variable outside their official scope and the result will be compiler-dependent and not portable. For example, a loop variable has only a language-defined value inside the loop, but in some compilers and languages (I don't remember if this was Turbo C++ or Turbo Pascal) you can still access its value outside the loop block after it terminated. Given that the behaviour is undefined, the result is outside the language official semantics, but some programs will still be coded in this way and have its running behavior dependent of this "undocumented feature". Diego (talk) 17:55, 23 February 2012 (UTC)

I disagree with your assessment. I think it would be more accurate to say that in some compilers and languages, a variable-name has a wider scope than is immediately obvious, or than is provided for by the language specification. —Ruakh_TALK 18:03, 23 February 2012 (UTC)

No, the scope of the variable is defined by the language semantics, not the compiler implementation (this is why we say the behaviour is "undefined", not "defined by the compiler"). In this compiler the variable is used outside the scope.

In C in particular, you can also access the memory space of a local variable through a pointer after the scope has finished. This is another instance of the variable "existing outside its scope".

Your version of the lead is better than the previous existing one; but I wanted to first 1) clarify this point, and 2) avoid that the scope definition mainly depends on the definition of "bound", which it was before. Explaining what happens to the variable when it's outside its scope is a good way to understand what happens when it's inside it. Diego (talk) 18:15, 23 February 2012 (UTC)

Re: first paragraph: I think you're talking out of both sides of your mouth. Either what's relevant is the de jure language semantics, in which case the variable-name does not exist outside of its scope (because it doesn't exist outside its official scope), or what's relevant is the de facto language semantics implemented by the compiler, in which case the variable-name does not exist outside of its scope (because its scope is wider than its official scope). It's perfectly valid to discuss, and contrast, both of these, but we shouldn't try to blur them by making statements that refer partly to each and are true of neither. (And by the way, if you have any evidence that referring to a variable outside of its scope is "undefined behavior" in any language other than C and C++, I'd be glad to see it.)

Re: second paragraph: That's completely irrelevant to this discussion, which is about whether a declaration or identifier exists outside of its scope. The statement "the variable exists outside of its scope, and can be accessed via a pointer" is true for one sense of "variable", but the statement "the variable-name exists outside of its scope, and can be accessed via a pointer" would be false. The latter is what's relevant to a discussion of identifiers. (Don't get me wrong, I think the former is absolutely worth mentioning; but it doesn't justify removing a correct statement about identifiers.)

Re: third paragraph: I'm not the one who introduced the word "bound". I tried to avoid it initially when I rewrote the lead text, but when you restored it, I had to admit that your version was less awkward than "the context within which a[n …] identifier identifies what it identifies", so I left it be.

—Ruakh_TALK 18:38, 23 February 2012 (UTC)

I've reviewed my edits, and with your comments now I see where you're coming from. A variable is actually comprised of two parts, a name and a data storage location. My sentences make sense if you think of the "storage" part, which still exists outside the scope of the "name" part.

I was confused by your use of "variable-*dash*-name", which is a non-standard way to write it and not used in the target article Variable (computer science); thus it isn't clear what its meaning is in the lead. I did not understand that you were referring only to the name in the rest of the paragraph; my sentences were referring to the variable as a whole, and the data storage location in particular. Note that when talking only about the variable name you're describing a particular form of identifier, so it's redundant with the other assertions about identifiers.

Now can we edit the lead so that distinction between the scope of the variable name and the access to the variable storage is clear? Diego (talk) 22:11, 23 February 2012 (UTC)

Re: your first paragraph: I still don't think your sentences made sense, because although the term "variable" is genuinely ambiguous between {name} and {name + storage}, the term "identifier" does not share that ambiguity. A variable's storage can indeed exist while its name is out of scope, but you used that fact to justify removing a sentence that didn't even mention variables! But if we're on the same page now, then I don't suppose it matters.

Re: first part of your second paragraph: I'm surprised that you find "variable-name" confusing, but by all means, we can change it to "variable name".

Re: "when talking only about the variable name you're describing a particular form of identifier": yes, exactly; re: "so it's redundant with the other assertions about identifiers": not at all. I was perfectly aware that variable-names are one kind of identifier, and therefore avoided such redundancy. Sometimes I made a statement about identifiers in general; sometimes I made a statement only about variable-names (when it didn't seem worth elaborating on how it applied to other identifiers); and sometimes I made a statement about variable-names, followed by a mention of "other identifiers".

Re: your last paragraph: yes, certainly, if you wish. I've never objected to that.

—Ruakh_TALK 01:43, 24 February 2012 (UTC)

Understanding Lexical/Dynamic Scoping

So I came here following some link trying to find out what exactly the difference between Lexical/Dynamic Scoping is. I read through the page for a few minutes and actually still hadn't much of a clue. Then I went to this page: http://c2.com/cgi/wiki?DynamicScoping

It's very easy to understand from these two paragraphs:

"In lexical scoping (and if you're the interpreter), you search in the local function (the function which is running now), then you search in the function (or scope) in which that function was defined, then you search in the function (scope) in which that function was defined, and so forth. "Lexical" here refers to text, in that you can find out what variable is being referred to by looking at the nesting of scopes in the program text.

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."

In contrast to this the text here goes:

"In lexical scoping (or lexical scope; also called static scoping or static scope), if a variable name's scope is a certain function, then its scope is the program text of the function definition: within that text, the variable name exists, and is bound to its variable, but outside that text, the variable name does not exist. By contrast, in 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. "

I don't know, but this doesn't make much sense to me. I'm trying to understand what it tries to express but it isn't easy, even though I know from the above explanation what the whole thing tries to express.

--Birgitschrange (talk) 10:55, 5 January 2013 (UTC)

Your information is very helpful to me. I've developed the habit, when consulting WP, of going right to the talk pages, due to the (in my amateur opinion) unclear expositions I often find in articles (I nevertheless have benefitted greatly from WP and am grateful to all those who have worked on it). Actually, I have the same problem on the internet in general - it's hard to find good explanations. The explanation you have here seems to draw a very clear distinction. ---lifeform (talk) 00:43, 6 December 2014 (UTC)

Omission of Basic programming language

I was hoping to find references to the history of variable scoping in the Basic programming language. Was Microsoft Visual Basic the first to implement this feature/concept? Linhartr22 (talk) 16:51, 21 July 2013 (UTC)

A few background points about the history of variable scoping. Variable scoping or lexical scoping was first used in Algol 60 in the 1960s [I was working on computers in the late 1960s. Algol 60 was the second language I learned after Fortran.] There is I think little doubt that this is the correctly stated origin of scoping; in fact the wikipedia article on Algol 60 says so more or less. Visual Basic was introduced as a new name in the early 1990s. The original "Basic" (without Visual) dates back to the early 1960s, but had no lexical scoping. From the 1970s onwards, following the success of Algol60, a majority of general purpose programming languages used Algol-style scoping. — Preceding unsigned comment added by SamLinscho (talk • contribs) 21:36, 29 May 2021 (UTC)

Wrong reference to code

File scope ends with a reference to C code that does not exist in the text. However, perhaps the author was referring to the Python code above (because of the function name)? — Preceding unsigned comment added by Polariseke (talk • contribs) 04:24, 1 December 2014 (UTC)

Visual Editor 'invented' additional changes

In this diff https://wiki.riteme.site/w/index.php?title=Scope_%28computer_science%29&type=revision&diff=762080509&oldid=753892005 I am only responsible for the change in the perl code example. The Visual Editor invented all the other changes. 93.232.43.102 (talk) 14:56, 26 January 2017 (UTC)

BLOCK and BEGIN

Fortran has BLOCK which in addition to the usual scope nesting, allows variables to be allocated. More specifically, arrays can be allocated with dimension based on values when entering the BLOCK. PL/I BEGIN blocks also do this, I believe inherited from ALGOL's BEGIN. There is no mention of Fortran, BLOCK, PL/I, and its BEGIN. As well as I know it, the lexical scope in C doesn't do allocation such that variables are still allocated at function entry. Gah4 (talk) 17:41, 31 July 2019 (UTC)

Perl example at Block scope section is obscure

The text and the code sample for the last Perl example simply do not match. The code is a closure factory, the text describes a single function closing over one variable. IMHO, a simpler code sample would be a better match for this article.

The code behaves like this (Perl v5.28.2):

sub increment_counter {
    my $counter = 0;
    return sub
    {
        return ++$counter;
    }
}

$c1 = increment_counter();
$c2 = increment_counter();

print &$c1(), "\n"; # -> 1
print &$c1(), "\n"; # -> 2
print &$c1(), "\n"; # -> 3

print &$c2(), "\n"; # -> 1
print &$c2(), "\n"; # -> 2

I changed (judging from browsing through the page history, it's probably a simple revert to some previous state) the code example to match the textual explanation:

{
  my $counter = 0;
  sub increment_counter {
      return  ++$counter;
  }
}

This does what's described.

2A02:AB88:1541:8C00:5810:A015:AC18:6016 (talk) 13:25, 17 March 2021 (UTC)

Macro Expansion section

In general, in C or C++, it is good form to parenthesize every parameter to a macro in its definition, as well as the entire definition. For example:

#define ADD_A(x) ((x) + a)

I'm not making the edit myself, because I'm not sure if it would add unnecessary complexity to the article. The example given does not have any actual bugs. To understand why this convention exists, please consider the following examples:

/* Bad smell */
#define PLUS(x, y) x + y

/* Idiomatic version */
#define BETTER_PLUS(x, y) ((x) + (y))

/* This is why parentheses are recommended around the whole expansion. */
a1 = w * PLUS(x, y);        /* w and x are multiplied, then the result is added to y... probably unexpected! */
a2 = w * BETTER_PLUS(x, y); /* x and y are added, then w is multiplied by the result, so a2 has the expected value. */

/* This is why parentheses are recommended around the arguments when they occur in the expansion. */
a3 = PLUS(w = x, y);        /* x is added to y, then the result is stored in w... probably unexpected! */
a4 = BETTER_PLUS(w = x, y); /* x's value is stored in w, then that same value is added to y afterwards to calculate a4, so w has the expected value. */

Having two different language constructs (function-like macros and actual functions) with the same syntax and different semantics invites error, but that's what C and C++ are like. Augmenting the language's actual definition with this convention makes the semantics of function-like macros more similar to those of functions at the point of use (though they are still not identical).

Duplicated Lexical vs. Dynamic sections

The page has two "Lexical scope vs. dynamic scope" sections. Need to eliminate one of them! — Preceding unsigned comment added by 131.119.15.14 (talk) 14:38, 9 June 2022 (UTC)