Talk:Global variable

message: Disagree that global variables to be merged into scope of programming because there's other meaning of global variables for different field, such as economic, sustainable development.
I also disagree with the merge.  While scope is very relevant to global variables, the term "global" refers specifically to the widest scope, and use of that particular scope level should be restricted.  The two topics are, however, connected, and the articles should definately reference each other.  scot 16:51, 3 November 2005 (UTC)

message: "The use of global variables is particularly bad for functional programming languages (such as Haskell). It violates referential transparency and makes it very difficult to analyze code."
It should be obvious that global variables can cause absolutely no problems with functional programming and they cannot violate referential transparency because in functional code they are immutable (as in Haskell).
They also don't increase the difficulty of code analysis.
The only place that global variables can violate referential transparency is in non-functional programming where they are mutable, and this has nothing to do with being global -- it has to do with their being mutable.
Local variables can also violate referential transparency in these situations. e.g.
 (let ((a 1) (b 0))
   (define (foo)
     a)
   (set! b (+ b (foo)))
   (set! a 2)
   (set! b (+ b (foo))))  —Preceding unsigned comment added by 203.222.167.145 (talk) 04:04, 30 November 2010 (UTC)
thread_title:  Removed this obviously incorrect paragraph 

message: (a) Scheme is a procedural language.
:: Changed to Haskell Traxer (talk) 17:03, 3 November 2010 (UTC)
replies: text:  Yes, they do. When a call f(x) to a function f modifies a global variable, that function call cannot be replaced by the value returned by f, because calls (to f or other functions) might return different values due to the global variable having a different value than when f(x) was actually executed. Traxer (talk) 17:03, 3 November 2010 (UTC)
replies: text:  And the same applies to local variables captured via lexical closure. Being global is irrelevant to this. 
  (let ((a 10))
    (lambda ()
      (set! a (+ a 1))
      a))
The problem is due to free variables in the presence of mutation. Global scope is completely irrelevant.
—Preceding unsigned comment added by 203.222.167.145 (talk) 08:20, 12 November 2010 (UTC)
thread_title:  The scheme reference is incorrect 

message: Just thought I would mention that in the example provided, int global is not truly "global" in scope but merely at file scope, which is the widest scope possible in C++ (and C).  Oddity- (talk) 17:45, 8 November 2009 (UTC)
thread_title:  C++ Example is incorrect 

message: What is the semantical difference in C between a global variable (being declared as int a) and a static global variable (being declared as static int a, see static variable)? 
Thanks, --Abdull (talk) 17:22, 7 January 2010 (UTC)
thread_title:  static and global in C 

message: Surely global variables are safe if they are rendered read only by any mechanism, including compilers and interpreters enforcing them as read only irrespectively of implementation details? 1Z (talk) 17:26, 16 July 2011 (UTC)
thread_title:  Protected memory versus read only 

message: "where each file defines an implicit namespace eliminate most of the problems seen with languages with a global namespace "
File level namespaces per se don't eliminate any problems. If globals are enforced to be read only, action at a distance becomes impossible. However, it is perfectly possible, naturally or artificially, for an entire programme to reside in one file , so that file scope = global scope. 
What's more, there are scopes wider than programme scope. Environment variables in *nix systems can apply
to any number of processes with a commmon ancestor.Of course they are safe because they cannot be written
to non-locally (writes only propagate down to grandchildren). 1Z (talk) 17:46, 16 July 2011 (UTC)
thread_title: System versus global versus file level sscope 

message: The article lacks fundamental descriptions between field uses. A well rounded global variables library for bed file i/o functionality, Staqtapp library @github, actually improves merge accuracy regarding descriptions point to point of global scopes if advanced implemented; or customized to the calling mechanics that could change. This change functionality is not a precedent limit of represented simulation of the merged variable definitions definitely as the article suggests repeatedly. Lastforkbender (talk) 20:28, 15 December 2023 (UTC)
thread_title:  Corresponding simulation aspects of global variables vs bed file direction of global variables