Rosetta Code

Scope modifiers

Revision as of 20:23, 28 March 2014 by rosettacode>AndiPersti (→‎{{header|bc}}: Rephrased second paragraph)

Most programming languages offer support for subroutines. When execution changes between subroutines, different sets of variables and functions ("scopes") are available to the program. Frequently these sets are defined by the placement of the variable and function declarations ("static scoping" or "lexical scoping"). These sets may also be defined by special modifiers to the variable and function declarations.

Task
Scope modifiers
You are encouraged to solve this task according to the task description, using any language you may know.

Show the different scope modifiers available in your language and briefly explain how they change the scope of their variable or function. If your language has no scope modifiers, note it.

Ada

Public and private declarative parts

In Ada declarative region of a package has publicly visible and private parts. The private part is introduced by private: <lang ada>package P is 

  ... -- Declarations placed here are publicly visible

private 

  ... -- These declarations are visible only to the children of P

end P;</lang> Correspondingly a type or object declaration may be incomplete in the public part providing an official interface. For example: <lang ada>package P is 

  type T is private; -- No components visible
  procedure F (X : in out T); -- The only visible operation
  N : constant T; -- A constant, which value is hidden

private 

  type T is record -- The implementation, visible to children only
     Component : Integer;
  end record;
  procedure V (X : in out T); -- Operation used only by children
  N : constant T := (Component => 0); -- Constant implementation

end P;</lang>

Bodies (invisible declarations)

The keyword body applied to the packages, protected objects and tasks. It specifies an implementation of the corresponding entity invisible from anywhere else: <lang ada>package body P is 

  -- The implementation of P, invisible to anybody
  procedure W (X : in out T); -- Operation used only internally

end P;</lang>

Private children

The keyword private can be applied to the whole package, a child of another package: <lang ada>private package P.Q is 

  ... -- Visible to the siblings only

private 

  ... -- Visible to the children only

end P.Q;</lang> This package can be then used only by private siblings of the same parent P.

AutoHotkey

Search autohotkey.com: modifiers
<lang AutoHotkey>singleton = "global variable"

assume_global() { 

 Global  ; assume all variables declared in this function are global in scope
 Static callcount := 0   ; except this one declared static, initialized once only
 MsgBox % singleton  ; usefull to initialize a bunch of singletons
 callcount++

}

assume_global2() { 

 Local var1  ; assume global except for var1  (similar to global scope declaration)
 MsgBox % singleton

}

object(member, value = 0, null = 0) { 

 Static  ; assume all variables in this function to be static
 If value    ; can be used to simulate objects

_%member% := value 

 Else If null

_%member% := "" 

 Return (_%member%)

}</lang>

BASIC

Applesoft BASIC

All variables are global by default, except the parameter which is local to the function. There are no scope modifiers. <lang ApplesoftBasic> 10 X = 1 

20  DEF  FN F(X) = X
30  DEF  FN G(N) = X
40  PRINT  FN F(2)
50  PRINT  FN G(3)</lang>

Output: 

2
1

BBC BASIC

Works with: BBC BASIC for Windows

All variables are global by default, except formal parameters which are local to the function.

The scope modifier LOCAL declares a variable local to a function; it sets the value to zero/NULL.

The scope modifier PRIVATE declares a variable static to a function; it sets the value to zero/NULL initially. <lang bbcbasic> var1$ = "Global1" 

     var2$ = "Global2"
     
     PRINT "Before function call:"
     PRINT "var1$ = """ var1$ """"
     PRINT "var2$ = """ var2$ """"
     
     PROCtestscope(var1$)
     PROCtestscope(var1$)
     
     PRINT "After function call:"
     PRINT "var1$ = """ var1$ """"
     PRINT "var2$ = """ var2$ """"
     END
     
     DEF PROCtestscope(var2$)
     PRINT "On entry to function:"
     PRINT "var1$ = """ var1$ """"
     PRINT "var2$ = """ var2$ """"
     
     LOCAL var1$
     PRIVATE var2$
     PRINT "After LOCAL/PRIVATE:"
     PRINT "var1$ = """ var1$ """"
     PRINT "var2$ = """ var2$ """"
     
     var1$ = "Local"
     var2$ = "Private"
     PRINT "After assignments:"
     PRINT "var1$ = """ var1$ """"
     PRINT "var2$ = """ var2$ """"
     
     ENDPROC</lang>

Output: 

Before function call:
var1$ = "Global1"
var2$ = "Global2"
On entry to function:
var1$ = "Global1"
var2$ = "Global1"
After LOCAL/PRIVATE:
var1$ = ""
var2$ = ""
After assignments:
var1$ = "Local"
var2$ = "Private"
On entry to function:
var1$ = "Global1"
var2$ = "Global1"
After LOCAL/PRIVATE:
var1$ = ""
var2$ = "Private"
After assignments:
var1$ = "Local"
var2$ = "Private"
After function call:
var1$ = "Global1"
var2$ = "Global2"

bc

All identifiers are global by default (except function parameters which are local to the function). There is one scope modifier: auto. All identifiers following the auto statement are local to the function and it must be the first statement inside the function body if it is used. Furthermore there can only be one auto per function.

One can think of each identifier as a stack. Function parameters and local identifiers are pushed onto the stack and shadow the values of identifiers with the same names from outer scopes. They are popped from the stack when the function returns. Thus a function that is called from another function has access to the local identifiers and parameters of its caller if itself doesn't use the same name as a local identifier/parameter. In other words, always the innermost value (the value at the top of the stack) for each identifier is visible, regardless of the scope level where it is accessed.

<lang bc>define g(a) { 

   auto b
   
   b = 3

   "Inside g: a = "; a
   "Inside g: b = "; b
   "Inside g: c = "; c
   "Inside g: d = "; d

   a = 3; b = 3; c = 3; d = 3

}

define f(a) { 

   auto b, c

   b = 2; c = 2
   "Inside f (before call): a = "; a
   "Inside f (before call): b = "; b
   "Inside f (before call): c = "; c
   "Inside f (before call): d = "; d
   x = g(2)    /* Assignment prevents output of the return value */
   "Inside f (after call): a = "; a
   "Inside f (after call): b = "; b
   "Inside f (after call): c = "; c
   "Inside f (after call): d = "; d

   a = 2; b = 2; c = 2; d = 2

}

a = 1; b = 1; c = 1; d = 1 "Global scope (before call): a = "; a "Global scope (before call): b = "; b "Global scope (before call): c = "; c "Global scope (before call): d = "; d x = f(1) "Global scope (before call): a = "; a "Global scope (before call): b = "; b "Global scope (before call): c = "; c "Global scope (before call): d = "; d</lang>

Output:
Global scope (before call): a = 1
Global scope (before call): b = 1
Global scope (before call): c = 1
Global scope (before call): d = 1
Inside f (before call): a = 1
Inside f (before call): b = 2
Inside f (before call): c = 2
Inside f (before call): d = 1
Inside g: a = 2
Inside g: b = 3
Inside g: c = 2
Inside g: d = 1
Inside f (after call): a = 1
Inside f (after call): b = 2
Inside f (after call): c = 3
Inside f (after call): d = 3
Global scope (before call): a = 1
Global scope (before call): b = 1
Global scope (before call): c = 1
Global scope (before call): d = 2

C

The only scope modifier in C is static. The keyword static can make a global variable local to the file where it is declared (it has file scope); but it has a different meaning used inside functions or blocks. The extern keyword allows to access a "global" variable defined somewhere else.

file1.c <lang c>int a; // a is global static int p; // p is "locale" and can be seen only from file1.c

extern float v; // a global declared somewhere else

// a "global" function int code(int arg) { 

 int myp;        // 1) this can be seen only from inside code
                 // 2) In recursive code this variable will be in a 
                 //    different stack frame (like a closure)
 static int myc; // 3) still a variable that can be seen only from
                 //    inside code, but its value will be kept
                 //    among different code calls
                 // 4) In recursive code this variable will be the 
                 //    same in every stack frame - a significant scoping difference

}

// a "local" function; can be seen only inside file1.c static void code2(void) { 

 v = v * 1.02;    // update global v
 // ...

}</lang>

file2.c <lang c>float v; // a global to be used from file1.c too static int p; // a file-scoped p; nothing to share with static p 

                // in file1.c

int code(int); // this is enough to be able to use global code defined in file1.c 

                // normally these things go into a header.h

// ...</lang>

Common Lisp

Common Lisp has exactly one scope modifier, the special declaration, which causes occurrences of a variable within the scope of the declaration to have dynamic scope ("special variables") rather than lexical scope.

The defining operators defvar and defparameter globally declare a variable special, though this can also be done using declaim. Local special declarations are rarely used.

The next example declaims that *bug* has dynamic scope. Meanwhile, shape has lexical scope.

<lang lisp>;; *bug* shall have a dynamic binding. (declaim (special *bug*))

(let ((shape "triangle") (*bug* "ant")) 

 (flet ((speak ()
          (format t "~%  There is some ~A in my ~A!" *bug* shape)))
   (format t "~%Put ~A in your ~A..." *bug* shape)
   (speak)
   
   (let ((shape "circle") (*bug* "cockroach"))
     (format t "~%Put ~A in your ~A..." *bug* shape)
     (speak))))</lang>

The function speak tries to use both *bug* and shape. For lexical scope, the value comes from where the program defines speak. For dynamic scope, the value comes from where the program calls speak. So speak always uses the same "triangle", but can use a different bug. 

Put ant in your triangle...
  There is some ant in my triangle!
Put cockroach in your circle...
  There is some cockroach in my triangle!

The stars around *bug* are not a special syntax. Rather, they are part of the symbol's name. This widely-used convention effectively places dynamic variables into their own namespace, which is necessary for preventing bugs. Common Lisp itself follows this tradition in its standard dynamic variables like *print-circle*, *readtable* et cetera.

Delphi

<lang Delphi>private</lang> Can only be seen inside declared class.


<lang Delphi>protected</lang> Can be seen in descendent classes.


<lang Delphi>public</lang> Can be seen from outside the class.


<lang Delphi>protected</lang> Same visibility as Public, but run time type information (RTTI) is generated, allowing these members to be viewed dynamically. Members need to be published in order to be streamed or shown in the Object Inspector.


<lang Delphi>automated</lang> Same visibility as Public, and used for Automation Objects. This is currently only maintained for backward compatibility.


<lang Delphi>strict private strict protected</lang> Private and Protected members of a class are visible to other classes declared in the same unit. The "strict" modifier was added in Delphi 2005 to treat public and private members as private and protected, even from classes declared in the same unit.

Déjà Vu

Variables are lexically scoped in Déjà Vu. Doing a set or a get starts looking for local declarations in the current scope, going upward until the global scope. One can use setglobal and getlocal to bypass this process, and only look at the global scope. <lang dejavu>set :a "global" if true: 

   !print a
   local :a "local"
   !print a
   !print getglobal :a

!print a </lang>

Output:
global
local
global
global

E

E has no scope modifiers; all variables (including function definitions) are lexical. When more than one file is involved, all import/export of definitions is handled by explicit return values, parameters, or reified environments.

Ela

Variables in Ela are lexically scoped (pretty similar to Haskell) and can be declared using let/in and where bindings. Additionally Ela provides a 'private' scope modifier for global bindings:

<lang ela>pi # private pi = 3.14159

sum # private sum x y = x + y</lang>

Names declared with 'private' modifier are not visible outside of a module. All other bindings are visible and can be imported. It is an error to use 'private' modifier on local bindings.

Erlang

Erlang is lexically scoped. Variables, which must begin with an upper case letter, are only available inside their functions. Functions are only available inside their modules. Unless they are exported. <lang Erlang> -module( a_module ).

-export( [double/1] ).

double( N ) -> add( N, N ).


add( N, N ) -> N + N. </lang>

Output:
3> a_module:double( 3 ).
6
4> a_module:add( 3, 3 ).
** exception error: undefined function a_module:add/2

Go

Go is lexically scoped and has just one scope modification feature, exported identifiers. Identifiers—variables and field names—are not visible outside of the package in which they are defined unless they begin with an upper case letter, as defined by Unicode class "Lu".


Haskell

Haskell has no scope modifiers; all variables are lexically scoped.

Site of declaration Scope
Top level The current module
where construct The definition to which the where is attached
let or case expression or lambda The entire expression
<- or let in a do block All statements in the do block after the declaration

Icon and Unicon

Icon and Unicon data types are not declared and variables can take on any value; however, variables can be declared as to their scope. For more see un-Declarations it's all about scope. Additionally, Unicon supports classes with methods. <lang Icon>global var1 # used outside of procedures

procedure one() # a global procedure (the only kind) local var2 # used inside of procedures static var3 # also used inside of procedures end</lang>

Co-expressions (both languages) also redefine scope - any local variables referenced within the body of a co-expression are restricted in scope to that body, but are initialized to the values they had with the co-expression is created.

J

J's scoping rules are dynamic scope, limited to behave as lexical scope.

First approximation: All variables are either "global" in scope, or are local to the currently executing explicit definition. Local names shadow global names. J provides kinds of assignment -- assignment to a local name (=.) and assignment to a global name (=:). Shadowed global names ("global" names which have the same name as a name that has a local definition) can not be assigned to (because this is typically a programming mistake and can be easily avoided by performing the assignment in a different execution context). Here's an interactive session:

<lang J> A=: 1 

  B=: 2
  C=: 3
  F=: verb define
     A=:4
     B=.5
     D=.6
     A+B+C+D
  )
  F

18 

  A

4 

  B

2 

  D

|value error</lang>

Second approximation: J does not really have a global namespace. Instead, each object and each class has its own namespace. By default, interactive use updates the namespace for the class named 'base'. Further discussion of this issue is beyond the scope of this page.

Java

<lang java>public //any class may access this member directly

protected //only this class, subclasses of this class, //and classes in the same package may access this member directly

private //only this class may access this member directly

static //for use with other modifiers //limits this member to one reference for the entire JVM

//adding no modifier (sometimes called "friendly") allows access to the member by classes in the same package

// Modifier | Class | Package | Subclass | World // ------------|-------|---------|----------|------- // public | Y | Y | Y | Y // protected | Y | Y | Y | N // no modifier | Y | Y | N | N // private | Y | N | N | N

//method parameters are available inside the entire method

//Other declarations follow lexical scoping, //being in the scope of the innermost set of braces ({}) to them. //You may also create local scopes by surrounding blocks of code with braces.

public void function(int x){ 

  //can use x here
  int y;
  //can use x and y here
  {
     int z;
     //can use x, y, and z here
  }
  //can use x and y here, but NOT z

}</lang>

JavaScript

There are not precisely any scope modifiers in JavaScript.

The var variable declaration makes a variable local to a function, and function parameters are also local. Any variable not so declared is global, except in ES5 strict mode where an undeclared variable is an error.

A named function definition (function foo() { ... }) is “hoisted” to the top of the enclosing function; it is therefore possible to call a function before its definition would seem to be executed.

Liberty BASIC

Functions, subroutines and variables are not declared before use.

Single-dimensioned arrays with 0-10 elements do not need to be declared or dimensioned before use.

Single-dimensioned arrays with indices greater than 10 and double-dimensioned arrays must be dimensioned before use.

There are two types of variables: string and numeric. Variables are visible in the scope in which they appear. unless they are declared GLOBAL.

Global variables are visible in all scopes.

Local variables may be passed ByRef and then become visible inside subs and functions.

Some entitities are global by default. These include arrays, structs, handles and special variables such as DefaultDir$, WindowWidth, and ForegroundColor$

Traditional Logo has dynamic scope for all symbols except for parameters, ostensibly so that it is easy to inspect bound values in an educational setting. UCB Logo also has a LOCAL syntax for declaring a dynamically scoped variable visible to a procedure and those procedures it calls. <lang logo> make "g 5  ; global

to proc :p 

 make "h 4    ; also global
 local "l       ; local, no initial value
 localmake "m 3

 sub 7

end

to sub :s 

 ; can see :g, :h, and :s
 ; if called from proc, can also see :l and :m
 localmake "h 5     ; hides global :h within this procedure and those it calls

end </lang>

Logtalk

Logtalk supports scope modifiers in predicate declarations and entity (object, category, or protocol) relations. By default, predicates are local (i.e. like private but invisible to the reflection mechanisms) and entity relations are public (i.e. not change to inherited predicate declarations is applied). <lang logtalk>

- public(foo/1).  % predicate can be called from anywhere
- protected(bar/2).  % predicate can be called from the declaring entity and its descendants
- private(baz/3).  % predicate can only be called from the declaring entity
- object(object,  % predicates declared in the protocol become private for the object
   implements(private::protocol)).
- category(object,  % predicates declared in the protocol become protected for the category
   implements(protected::protocol)).
- protocol(extended, % no change to the scope of the predicates inherited from the extended protocol
   extends(public::minimal)).

</lang>

Mathematica

<lang Mathematica>Module -> localize names of variables (lexical scoping) Block -> localize values of variables (dynamic scoping)

Module creates new symbols:

Module[{x}, Print[x]; 

Module[{x}, Print[x]]

]

->x$119 ->x$120

Block localizes values only; it does not create new symbols:

x = 7; Block[{x=0}, Print[x]] Print[x] ->0 ->7</lang>

MUMPS

MUMPS variable can be in a local scope if they are declared as NEW within a subroutine. Otherwise variables are accessible to all levels. <lang MUMPS>OUTER 

SET OUT=1,IN=0
WRITE "OUT = ",OUT,!
WRITE "IN = ",IN,!
DO INNER
WRITE:$DATA(OUT)=0 "OUT was destroyed",!
QUIT

INNER 

WRITE "OUT (inner scope) = ",OUT,!
WRITE "IN (outer scope) = ",IN,!
NEW IN
SET IN=3.14
WRITE "IN (inner scope) = ",IN,!
KILL OUT
QUIT</lang>

Execution:

USER>D ^SCOPE
OUT = 1
IN = 0
OUT (inner scope) = 1
IN (outer scope) = 0
IN (inner scope) = 3.14
OUT was destroyed

PARI/GP

The modifiers are local and, for recent versions of Pari, my. See the User's Guide to PARI/GP.

Pascal

See Delphi

Perl

A name explicitly qualified as belonging to a package with :: (like $Foo::bar; as a special case, for any identifier var and sigil $, $::var is short for $main::var) always refers to a package variable, i.e., a global variable belonging to the given package. So only unqualified names can have context-sensitive interpretations.

By default, an unqualified name refers to a package variable in the current package. The current package is whatever you set it to with the last package declaration in the current lexical scope, or main by default. But wherever stricture is in effect, using a name that would be resolved this way is a compile-time error.

There are four kinds of declaration that can influence the scoping of a particular variable: our, my, state, and local. our makes a package variable lexically available. Its primary use is to allow easy access to package variables under stricture.

<lang perl>use strict; $x = 1; # Compilation error. our $y = 2; print "$y\n"; # Legal; refers to $main::y.

package Foo; our $z = 3; package Bar; print "$z\n"; # Refers to $Foo::z.</lang>

my creates a new lexical variable, independent of any package. It's destroyed as soon as it falls out of scope, and each execution of the statement containing the my creates a new, independent variable.

<lang perl>package Foo; my $fruit = 'apple'; package Bar; print "$fruit\n"; # Prints "apple". { 

   my $fruit = 'banana';
   print "$fruit\n";     # Prints "banana".

} print "$fruit\n"; # Prints "apple". 

                         # The second $fruit has been destroyed.

our $fruit = 'orange'; print "$fruit\n"; # Prints "orange"; refers to $Bar::fruit. 

                         # The first $fruit is inaccessible.</lang>

state is like my but creates a variable only once. The variable's value is remembered between visits to the enclosing scope. The state feature is only available in perl 5.9.4 and later, and must be activated with use feature 'state'; or a use demanding a sufficiently recent perl.

<lang perl>use 5.10.0;

sub count_up { 

   state $foo = 13;
   say $foo++;

}

count_up; # Prints "13". count_up; # Prints "14".</lang>

local gives a package variable a new value for the duration of the current dynamic scope.

<lang perl>our $camelid = 'llama';

sub phooey { 

   print "$camelid\n";

}

phooey; # Prints "llama".

sub do_phooey { 

   local $camelid = 'alpaca';
   phooey;

}

do_phooey; # Prints "alpaca". phooey; # Prints "llama".</lang>

Usually, my is preferable to local, but one thing local can do that my can't is affect the special punctuation variables, like $/ and $". Actually, in perl 5.9.1 and later, my $_ is specially allowed and works as you would expect.

Perl 6

Perl 6 has a system of declarators that introduce new names into various scopes. <lang perl6>my $lexical-variable; our $package-variable; state $persistent-lexical; has $.public-attribute;</lang> Lexically scoped variables, declared with my, are the norm. Function definitions are intrinsically lexical by default, but allow for forward references, unlike any other declaration.

Package variables, declared with our, are de-emphasized. Unlike in Perl 5, almost no built-ins use package declarations for anything other than type names, and most of Perl 5's global punctuational variables become dynamic variables instead, with the final recourse in the GLOBAL and PROCESS packages. The per-interpreter GLOBAL package is mainly for users; all predefined process-wide information is stored in the PROCESS symbol table instead. The our declarator actually just declares an alias to a variable of the same name in the current package, and is in a sense just permission to use that global variable in the current scope as if it were a lexical. Type and constant declarations, including enums, are intrinsically considered "our" declarations, since Perl 6 considers constants to be degenerate types.

State variables, declared with state, are persistent lexicals that are not re-initialized on each function entry, but retain their previous value. An initializer is run only the first time through. State variables are similar but not identical to C static variables; in Perl each closure clone gets its own state variable, since such closures are really a form of generic code.

The has declarator is for declaring items in object scope. Method declarations are implicitly in "has" scope.

In Perl 5, dynamic scoping is done via "local" to temporarily change the value of a global variable. This mechanism is still specced for Perl 6, albeit with a different keyword, temp, that better reflects what it's doing. None of the implementations yet implement temp, since Perl 6 does dynamic scoping via a more robust system of scanning up the call stack for the innermost dynamic declaration, which actually lives in the lexical scope of the function declaring it. We distinguish dynamic variables syntactically by introducing a "twigil" after the sigil. The twigil for dynamic variables is * to represent that we don't know how to qualify the location of the variable. <lang perl6>sub a { 

   my $*dyn = 'a';
   c();

} sub b { 

   my $*dyn = 'b';
   c();

} sub c { 

   say $*dyn;

} a(); # says a b(); # says b</lang> The standard IO filehandles are dynamic variables $*IN, $*OUT, and $*ERR, which allows a program to easily redirect the input or output from any subroutine and all its children. More generally, since most process-wide variables are accessed via this mechanism, and only look in the PROCESS package as a last resort, any chunk of code can pretend to be in a different kind of process environment merely by redefining one or more of the dynamic variables in question, such as %*ENV.

This mechanism automatically produces thread-local storage if you declare your dynamic variable inside the lexical scope of the thread.

PicoLisp

PicoLisp distinguishes between "scope" and "binding". The scope of a symbol determines its visibility in a given context (whether or not it can be accessed), while binding is about assigning it a value.

Scope

In PicoLisp, the scope type of a symbol is either "internal", "transient" or "external". It is specified lexically: Internal symbols are just normal symbols. Transient symbols are surrounded by double quotes (and thus look like strings in other languages), and/or with an underlined font if possible. External symbols are surrounded by braces.

  • The scope of an internal symbol is global. This means that a symbol like AB123 is always the same object, residing at a certain location in memory (pointer equality).
  • A transient symbol like "AB123" is the same only within the current transient scope. This is normally a single source file, but may be further subdivided. Within that scope it can be used like an internal symbol, but after the transient scope is closed it cannot be accessed by its name any longer. This behavior is similar to "static" identifiers in the C language.
  • External symbols like {AB123} are persistent database symbols. They have a permanent identity among different processes and over time. Besides that, they have the same structure like internal and transient symbols: A value, properties and a name.

Binding

Regardless of the scope, the binding of symbols to values is always dynamic. This happens implicitly for function parameters, or explicitly with functions like let, use, bind, job and others. This means that the current value of a symbol is saved locally, then set to the new value. When done, the old value is restored. Closures are created by maintaining an explicit environment. More about that here.

PowerShell

Variables can have a specific scope, which is one of global, local, script, private. Variables with the same name can exist in different scopes and are shadowed by child scopes. The scope of a variable can be directly prefixed to the variable name: <lang powershell>$a = "foo" # global scope function test { 

   $a = "bar"                    # local scope
   Write-Host Local: $a          # "bar" - local variable
   Write-Host Global: $global:a  # "foo" - global variable

}</lang> The various cmdlets dealing with variables also have a –Scope parameter, enabling one to specify a relative or absolute scope for the variable to be manipulated.

PureBasic

  • Functions must be defined before being used and are always global in scope.
  • Variables must be defined before being used. They do not have to be explicity defined, simply using them will define them. The keyword EnableExplicit may also be used to require explicit definitions before using a variable.
  • Two main divisions in scope exist. The first scope is the body of code outside of all procedures and the second is the scope within a single given procedure.
  • If a variable is not explicitly defined its scope is local to one of the aforementioned areas. This may be modified by using one of the keywords: Global, Protected, or Shared. The effects are detailed by the comments in the sample code.

<lang PureBasic>;define a local integer variable by simply using it baseAge.i = 10

explicitly define local strings

Define person.s = "Amy", friend.s = "Susan"

define variables that are both accessible inside and outside procedures

Global ageDiff = 3 Global extraYears = 5


Procedure test() 

 ;define a local integer variable by simply using it
 baseAge.i = 30
 ;explicitly define a local string
 Define person.s = "Bob"
 ;allow access to a local variable in the main body of code
 Shared friend
 ;create a local variable distinct from a variable with global scope having the same name
 Protected extraYears = 2
 
 PrintN(person + " and " + friend + " are " + Str(baseAge) + " and " + Str(baseAge + ageDiff + extraYears) + " years old.")

EndProcedure


If OpenConsole() 

 test()
 
 PrintN(person + " and " + friend + " are " + Str(baseAge) + " and " + Str(baseAge + ageDiff + extraYears) + " years old.")
 
 Print(#CRLF$ + #CRLF$ + "Press ENTER to exit")
 Input()
 CloseConsole()

EndIf</lang> Code output: 

Bob and Susan are 30 and 35 years old.
Amy and Susan are 10 and 18 years old.

Python

Python from version 3 has the global and nonlocal access modifiers:

  • global instructs the interpreter to search for the name(s) in the outermost sccope.
  • nonlocal instructs the interpreter to search for the name(s) starting from the innermost enclosing scope going outwards.

Without either keyword, a reference to a name must have the name defined in the current scope or if not, then it is looked for in the global scope - skipping any intermediate scopes.

In the example below the name x is defined at various scopes and given a different value dependent on its scope. The innermost functions demonstrate how the scope modifiers give acccess to the name from different scopes:

<lang python>>>> x="From global scope" >>> def outerfunc(): 

   x = "From scope at outerfunc"

   def scoped_local():
       x = "scope local"
       return "scoped_local scope gives x = " + x
   print(scoped_local())

   def scoped_nonlocal():
       nonlocal x
       return "scoped_nonlocal scope gives x = " + x
   print(scoped_nonlocal())

   def scoped_global():
       global x
       return "scoped_global scope gives x = " + x
   print(scoped_global())

   def scoped_notdefinedlocally():
       return "scoped_notdefinedlocally scope gives x = " + x
   print(scoped_notdefinedlocally())


>>> outerfunc() scoped_local scope gives x = scope local scoped_nonlocal scope gives x = From scope at outerfunc scoped_global scope gives x = From global scope scoped_notdefinedlocally scope gives x = From global scope >>></lang> More information on the scope modifiers can be found here.

R

See "How R Searches and Finds Stuff" for a thorough introduction to scoping, particularly the surprisingly complicated conventions for packages. For a briefer overview, read on.

In R, functions use lexical scope: a function acquires its parent scope at the time of definition, and each invocation creates a new local environment within that parent scope. Variable lookup during evaluation starts in the function's local environment and proceeds up the chain of parent environments.

<lang R>X <- "global x" f <- function() { 

 x <- "local x"
 print(x) #"local x"

} f() #prints "local x" print(x) #prints "global x"</lang>

attach() will attach an environment or data set to the chain of enclosing environments.

<lang R>d <- data.frame(a=c(2,4,6), b = c(5,7,9)) attach(d) b - a #success detach(d) b - a #produces error</lang>

Assignment using <- or -> by default happens in the local (innermost) environment. The <<- and ->> operators assign a variable in the innermost enclosing scope in which that variable is already defined, or the global environment if no enclosing definition is found.

<lang R>x <- "global x" print(x) #"global x"

local({ ## local({...}) is a shortcut for evalq({...}, envir=new.env()) 

       ## and is also equivalent to (function() {...})()
 
 x <- "outer local x"
 print(x)                                 #"outer local x"
 x <<- "modified global x"
 print(x)                                 #"outer local x" still
 y <<- "created global y"
 print(y)                                 #"created global y"
 local({
   
   ## Note, <<- is _not_ a global assignment operator. If an
   ## enclosing scope defines the variable, that enclosing scope gets
   ## the assignment. This happens in the order of evalution; a local
   ## variable may be defined later on in the same scope.
   
   x <- "inner local x"
   print(x)                               #"inner local x"
   x <<- "modified outer local x"
   print(x)                               #"inner local x"
   y <<- "modified global y"
   print(y)                               #"modified global y"
   y <- "local y"
   print(y)                               #"local y"
   
   ##this is the only way to reliably do a global assignment:
   assign("x", "twice modified global x", globalenv())
   print(evalq(x, globalenv()))           #"twice modified global x"
 })

 print(x)                                 #"modified outer local x"

}) print(x) #"twice modified global x" print(y) #"modified global y"</lang>

However, the scope and other aspects of evaluation can be explicitly manipulated at runtime. assign() and eval(), for instance, allow you to specify where an evaluation or assignment is to take place. parent.env() returns the lexically enclosing scope, while parent.frame() returns the immediate scope of the calling function.

<lang R>x <- "global x" f <- function() { 

 cat("Lexically enclosed x: ", x,"\n")
 cat("Lexically enclosed x: ", evalq(x, parent.env(sys.frame())),"\n")
 cat("Dynamically enclosed x: ", evalq(x, parent.frame()),"\n")

}

local({ 

 x <- "local x"
 f()

})</lang>

A function's arguments are not evaluated until needed; the function may change the evaluation rules for expressions given to its arguments by capturing its quoted argument via substitute() and evaluating it in a different environment. For instance, with() evaluates its second argument in the environment defined by its first argument, enclosed within the current scope.

<lang R>d <- data.frame(a=c(2,4,6), b = c(5,7,9)) also <- c(1, 0, 2) with(d, mean(b - a + also)) #returns 4

    1. with() is built in, but you might have implemented it like this:

with.impl <- function(env, expr) { 

 env <- as.environment(env)
 parent.env(env) <- parent.frame()
 eval(substitute(expr), envir=env)

} with.impl(d, mean(b - a + also))</lang>

Racket

Racket has no concept of scope modifiers. Depending on where an identifier is bound, it may be considered a top-level, module, or local binding. However, the binding is introduced with lexical scope in all cases. Bindings are introduced by syntactic forms such as lambda, let, or define.

However, Racket identifier bindings do exist at particular phase levels (represented by an integer). Phase levels, to a first approximation, allow the separation of computations that occur at compile-time and run-time.

REXX

In the REXX language, all variables are local, and only within PROCEDUREs are variables local (private), except
for those identified via the EXPOSE option. There is a variant where the EXPOSE can have a list specified.
Any REXX variables in an external routine (program) aren't known.
Note: the R4 REXX interpreter has an EXPOSEALL option that allows an external REXX subroutine to access the caller's local variables.
There is a mechanism that allows external programs to access local REXX variables and is essentially restricted to
assembler programs that use the REXXAPI interface.
All labels (names of subroutines/functions/procedures) are global.
If more than one identical label is specified, only the first label is recognized (and not considered an error). <lang rexx>/*REXX program to display scope modifiers (for subroutines/functions). */ a=1/4 b=20 c=3 d=5 call SSN_571 d**4 

      /* at this point,  A   is    defined and equal to      .25       */
      /* at this point,  B   is    defined and equal to    40          */
      /* at this point,  C   is    defined and equal to    27          */
      /* at this point,  D   is    defined and equal to     5          */
      /* at this point,  FF  isn't defined.                            */
      /* at this point, EWE  is    defined and equal to 'female sheep' */
      /* at this point,  G   is    defined and equal to   625          */

exit /*stick a fork in it, we're done.*/ /*─────────────────────────────────────SSN_571 submarine, er, subroutine*/ SSN_571: procedure expose b c ewe g; parse arg g b = b*2 c = c**3 ff = b+c ewe = 'female sheep' d = 55555555 return /*compliments to Jules Verne's Captain Nemo? */</lang>

Tcl

Variables

In Tcl procedures, variables are local to the procedure unless explicitly declared otherwise (unless they contain namespace separators, which forces interpretation as namespace-scoped names). Declarations may be used to access variables in the global namespace, or the current namespace, or indeed any other namespace.

Works with: Tcl version 8.5

<lang tcl>set globalVar "This is a global variable" namespace eval nsA { 

   variable varInA "This is a variable in nsA"

} namespace eval nsB { 

   variable varInB "This is a variable in nsB"
   proc showOff {varname} {
       set localVar "This is a local variable"
       global globalVar
       variable varInB
       namespace upvar ::nsA varInA varInA
       puts "variable $varname holds \"[set $varname]\""
   }

} nsB::showOff globalVar nsB::showOff varInA nsB::showOff varInB nsB::showOff localVar</lang> Output: 

variable globalVar holds "This is a global variable"
variable varInA holds "This is a variable in nsA"
variable varInB holds "This is a variable in nsB"
variable localVar holds "This is a local variable"

Objects have an extra variable access mode. All the variables declared in a class definition are visible by default in the methods defined in that class. All other variable access modes are still available too.

Works with: Tcl version 8.6

or

Library: TclOO

<lang tcl>oo::class create example { 

   # Note that this is otherwise syntactically the same as a local variable
   variable objVar
   constructor {} {
       set objVar "This is an object variable"
   }
   method showOff {} {
       puts "variable objVar holds \"$objVar\""
   }

}

[example new] showOff</lang>Output:

variable objVar holds "This is an object variable"

Commands

Tcl commands are strictly always scoped to a particular namespace (defaulting to the global namespace, which is just a normal namespace in a somewhat privileged position). Commands are looked up in the current namespace first, then according to the current namespace's path rules (always empty prior to Tcl 8.5), and then finally in the global namespace. This effectively puts the global namespace in the scope of every namespace (though override-able in every namespace as well). By convention, library packages are placed in namespaces other than the global one (except for legacy cases or a single package access command) so that they don't cause unexpected conflicts; typically the global namespace is reserved for the Tcl language and user applications.

General Caller Scope Access

Of considerable relevance to this area are the upvar and uplevel commands. The first allows a variable name to be resolved to a variable in the scope of a caller of the current procedure and linked to a local variable in the current stack frame, and the second allows the execution of arbitrary code in the context of a caller of the current procedure. Both can work with any stack frame on the call stack (which consequently becomes a call tree) but the two most commonly referred-to frames are the immediate caller of the current procedure and the global/topmost stack frame.

To demonstrate these capabilities, here is an example of how we can create a decr command that is just like the incr command except for working with increments in the opposite direction. <lang tcl>proc decr {varName {decrement 1}} { 

   upvar 1 $varName var
   incr var [expr {-$decrement}]

}</lang> Here is a kind of version of eval that concatenates its arguments with a semicolon first, instead of the default behavior (a space): <lang tcl>proc semival args { 

   uplevel 1 [join $args ";"]

}</lang> Of course, these capabilities are designed to be used together. Here is a command that will run a loop over a variable between two bounds, executing a "block" for each step. <lang tcl>proc loop {varName from to body} { 

   upvar 1 $varName var
   for {set var $from} {$var <= $to} {incr var} {
       uplevel 1 $body
   }

}

loop x 1 10 { 

   puts "x is now $x"
   if {$x == 5} {
       puts "breaking out..."
       break
   }

} puts "done"</lang> which prints: 

x is now 1
x is now 2
x is now 3
x is now 4
x is now 5
breaking out...
done

As you can see, these are very powerful capabilities which make it trivial to write control structures in next to no Tcl code at all.

TI-89 BASIC

The only scope modifier in TI-89 BASIC is the Local command, which makes the variable local to the enclosing program or function rather than global (in some folder).

<lang ti89b>Local x 2 → x Return x^x</lang>

TXR

Functions and filters are global in TXR. Variables are pattern matching variables and have a dynamically scoped discipline. The binding established in a clause is visible to other clauses invoked from that clause, including functions. Whether or not bindings survive from a given scope usually depends on whether the scope, overall, failed or succeeded. Bindings established in scopes that terminate by failing (or by an exception) are rolled back and undone. The @(local) or @(forget) directives, which are synonyms, are used for breaking the relationship between variables occuring in a scope, and any bindings those variables may have. If a clause declares a variable forgotten, but then fails, then this forgetting is also undone; the variable is known once again. But in successful situations, the effects of forgetting can be passed down.

Functions have special scoping and calling rules. No binding for a variable established in a function survives the execution of the function, except if its symbol matches one of the function parameters, call it P, and that parameter is unbound (i.e. the caller specified some unbound variable A as the argument). In that case, the new binding for unbound parameter P within the function is translated into a new binding for unbound argument A at the call site. Of course, this only happens if the function succeeds, otherwise the function call is a failure with no effect on the bindings.

Illustration using named blocks. In the first example, the block succeeds and so its binding passes on:

<lang txr>@(maybe)@# perhaps this subclause suceeds or not @ (block foo) @ (bind a "a") @ (accept foo) @(end) @(bind b "b")</lang>

Result: 

a="a"
b="b"

By contrast, in this version, the block fails. Because it is contained in a @(maybe), evaluation can proceed, but the binding for a is gone.

<lang txr>@(maybe)@# perhaps this subclause suceeds or not @ (block foo) @ (bind a "a") @ (fail foo) @(end) @(bind b "b")</lang>

Result: 

b="b"

Ursala

There are no variables in Ursala except dummy variables used in lambda abstractions, but scope rules govern the visibility of constants and function declarations.

When compiling a library, directives such as #library and #binary can be switched on and off throughout a source text, and only the symbols declared when they're on will become visible library entry points. <lang Ursala>local_shop = 0 hidden_variable = 3

  1. library+

this_public_constant = local_shop a_visible_function = +

  1. library-

for_local_people = 7</lang> By default, every symbol is visible to every other within the same file, and multiple declarations of the same symbol are an error, but the scope modifiers #hide and #export can create multiple scopes within a single file. In this example, the symbol x will have a value of 1, <lang Ursala>foo = 1

  1. hide+

foo = 2 bar = 3

  1. hide-

x = foo</lang> but it will be 2 in this example, where the #export directive selectively allows an otherwise hidden declaration to be visible outside its enclosing scope, and allows name clashes to be resolved by proximity. <lang Ursala>foo = 1

  1. hide+
  1. export+

foo = 2

  1. export-

bar = 3

  1. hide-

x = foo</lang> The #hide directives can be arbitrarily nested in matched pairs to create block structured scope, but doing so is likely to be overkill.

When name clashes occur between imported and locally declared symbols, they are resolved by default in favor of the local declaration. However, this behavior can be overridden using the dash operator as shown. <lang Ursala>#import std

cat = 3 a_string = std-cat('foo','bar')</lang> Here, std-cat refers to the concatenation function from the standard library, not the locally declared constant by that name.

zkl

Functions in zkl have only one scope: the class/file they are defined in. They are not lexically scoped, they are promoted to the "top" of their enclosing class (as are vars). They only have direct access to class instance data and their enclosing class (and its contained classes/data).

Functions can use lexically local data via closures but that is one way; changes do not "leak" back out. In order to escape, closed over data must be a [mutable] container or in a mutable container.

Side note: Classes are basically containers that hold data such as variables, functions/code, other classes and parents.

Retrieved from "https://rosettacode.org/wiki/Scope_modifiers?oldid=114922"