Scope modifiers: Difference between revisions

 

 

=={{header|Ada}}==

===Public and private declarative parts===

... -- Declarations placed here are publicly visible

private

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

Correspondingly a type or object declaration may be incomplete in the public part providing an official interface. For example:

type T is private; -- No components visible

procedure F (X : in out T); -- The only visible operation

procedure V (X : in out T); -- Operation used only by children

N : constant T := (Component => 0); -- Constant implementation

===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:

-- The implementation of P, invisible to anybody

procedure W (X : in out T); -- Operation used only internally

===Private children===

The keyword '''private''' can be applied to the whole package, a child of another package:

... -- Visible to the siblings only

private

... -- Visible to the children only

This package can be then used only by private siblings of the same parent P.

=={{header|AutoHotkey}}==

{{AutoHotkey case}}

 

assume_global()

_%member% := ""

Return (_%member%)

 

 

==={{header|Applesoft BASIC}}===

All variables are global by default, except the parameter which is local to the function. There are no scope modifiers.

20 DEF FN F(X) = X

30 DEF FN G(N) = X

40 PRINT FN F(2)

<pre>2

1

 

The scope modifier PRIVATE declares a variable static to a function; it sets the value to zero/NULL initially.

var2$ = "Global2"

PRINT "var2$ = """ var2$ """"

<pre>

Before function call:

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.

 

auto b

"Global scope (before call): b = "; b

"Global scope (before call): c = "; c

 

{{Out}}

Global scope (before call): c = 1

Global scope (before call): d = 2</pre>

 

=={{header|C}}==

 

'''file1.c'''

static int p; // p is "locale" and can be seen only from file1.c

 

v = v * 1.02; // update global v

// ...

 

'''file2.c'''

static int p; // a file-scoped p; nothing to share with static p

// in file1.c

// normally these things go into a header.h

 

 

 

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

 

The next example declaims that <code>*bug*</code> has dynamic scope. Meanwhile, <code>shape</code> has lexical scope.

 

(declaim (special *bug*))

 

(let ((shape "circle") (*bug* "cockroach"))

(format t "~%Put ~A in your ~A..." *bug* shape)

 

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

 

=={{header|Delphi}}==

Can only be seen inside declared class.

 

Can be seen in descendent classes.

 

Can be seen from outside the class.

 

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.

 

Same visibility as Public, and used for Automation Objects. This is currently only maintained for backward compatibility.

 

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.

=={{header|Déjà Vu}}==

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

if true:

!print a

!print getglobal :a

!print a

{{out}}

<pre>global

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.

 

 

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:

 

pi = 3.14159

 

sum # private

 

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.

=={{header|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.

-module( a_module ).

 

 

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

 

{{out}}

** exception error: undefined function a_module:add/2

</pre>

 

=={{header|Go}}==

Go is lexically scoped and has just one scope modification feature, exported identifiers. Identifiers&mdash;variables and field names&mdash;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".

 

=={{header|Haskell}}==

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

 

=={{header|Icon}} and {{header|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 [[Icon%2BUnicon/Intro#un-Declarations.2C_it.27s_all_about_Scope|un-Declarations it's all about scope]]. Additionally, Unicon supports classes with methods.

 

procedure one() # a global procedure (the only kind)

local var2 # used inside of procedures

static var3 # also used inside of procedures

 

Co-expressions (both languages) also redefine scope - any local variables referenced

 

=={{header|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 (<tt>=.</tt>) and assignment to a global name (<tt>=:</tt>). 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:

 

B=: 2

C=: 3

2

D

 

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.

 

=={{header|Java}}==

 

protected //only this class, subclasses of this class,

}

//can use x and y here, but NOT z

 

=={{header|JavaScript}}==

There are not precisely any scope ''modifiers'' in JavaScript.

 

 

A named function definition (<code>function foo() { ... }</code>) 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.

 

=={{header|Liberty BASIC}}==

=={{header|Logo}}==

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.

make "g 5 ; global

 

localmake "h 5 ; hides global :h within this procedure and those it calls

end

 

=={{header|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).

:- public(foo/1). % predicate can be called from anywhere

 

:- protocol(extended, % no change to the scope of the predicates inherited from the extended protocol

extends(public::minimal)).

 

 

 

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

 

=={{header|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.

SET OUT=1,IN=0

WRITE "OUT = ",OUT,!

WRITE "IN (inner scope) = ",IN,!

KILL OUT

Execution:<pre>

USER>D ^SCOPE

IN (inner scope) = 3.14

OUT was destroyed</pre>

 

=={{header|PARI/GP}}==

 

=={{header|Pascal}}==

 

=={{header|Perl}}==

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

 

$x = 1; # Compilation error.

our $y = 2;

our $z = 3;

package Bar;

 

<code>my</code> 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 <code>my</code> creates a new, independent variable.

 

my $fruit = 'apple';

package Bar;

our $fruit = 'orange';

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

 

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

 

 

sub count_up

 

count_up; # Prints "13".

 

<code>local</code> gives a package variable a new value for the duration of the current ''dynamic'' scope.

 

 

sub phooey

 

do_phooey; # Prints "alpaca".

 

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

 

 

 

 

 

 

 

=={{header|PicoLisp}}==

 

===Scope===

In PicoLisp, the scope type of a symbol is either "internal", "transient" or

Transient symbols are surrounded by double quotes (and thus look like strings in

 

* 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).

 

===Binding===

Regardless of the scope, the binding of symbols to values is always dynamic.

This happens implicitly for function parameters, or explicitly with functions

=={{header|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:

function test {

$a = "bar" # local scope

Write-Host Local: $a # "bar" - local variable

Write-Host Global: $global:a # "foo" - global variable

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.

=={{header|PureBasic}}==

* Functions must be defined before being used and are always global in scope.

 

* 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: <tt>Global</tt>, <tt>Protected</tt>, or <tt>Shared</tt>. The effects are detailed by the comments in the sample code.

baseAge.i = 10

;explicitly define local strings

Input()

CloseConsole()

<pre>Bob and Susan are 30 and 35 years old.

Amy and Susan are 10 and 18 years old.</pre>

In the example below the name <code>x</code> 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:

 

>>> def outerfunc():

x = "From scope at outerfunc"

scoped_global scope gives x = From global scope

scoped_notdefinedlocally scope gives x = From global scope

 

=={{header|R}}==

See [http://obeautifulcode.com/R/How-R-Searches-And-Finds-Stuff/ "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.

 

up the chain of parent environments.

 

f <- function() {

x <- "local x"

}

f() #prints "local x"

 

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

enclosing environments.

 

attach(d)

b - a #success

detach(d)

 

Assignment using <- or -> by default happens in the local

definition is found.

 

print(x) #"global x"

 

})

print(x) #"twice modified global x"

 

However, the scope and other aspects of evaluation can be

function.

 

f <- function() {

cat("Lexically enclosed x: ", x,"\n")

x <- "local x"

f()

 

A function's arguments are not evaluated until needed; the function

defined by its first argument, enclosed within the current scope.

 

also <- c(1, 0, 2)

with(d, mean(b - a + also)) #returns 4

eval(substitute(expr), envir=env)

}

 

=={{header|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 <tt>lambda</tt>, <tt>let</tt>, or <tt>define</tt>.

 

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.

 

=={{header|REXX}}==

a=1/4

b=20

ewe = 'female sheep'

d = 55555555

 

=={{header|Tcl}}==

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|8.5}}

namespace eval nsA {

variable varInA "This is a variable in nsA"

nsB::showOff varInA

nsB::showOff varInB

<pre>variable globalVar holds "This is a global variable"

variable varInA holds "This is a variable in nsA"

 

{{works with|Tcl|8.6}} or {{libheader|TclOO}}

# Note that this is otherwise syntactically the same as a local variable

variable objVar

}

}

 

===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 <code>upvar</code> and <code>uplevel</code> 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 <code>decr</code> command that is just like the <code>incr</code> command except for working with increments in the opposite direction.

upvar 1 $varName var

incr var [expr {-$decrement}]

Here is a kind of version of <code>eval</code> that concatenates its arguments with a semicolon first, instead of the default behavior (a space):

uplevel 1 [join $args ";"]

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.

upvar 1 $varName var

for {set var $from} {$var <= $to} {incr var} {

}

}

which prints:

<pre>x is now 1

 

=={{header|TI-89 BASIC}}==

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

 

2 → x

 

=={{header|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 <code>@(local)</code> or <code>@(forget)</code> 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.

 

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

 

@ (block foo)

@ (bind a "a")

@ (accept foo)

@(end)

 

 

<pre>a="a"

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

 

@ (block foo)

@ (bind a "a")

@ (fail foo)

@(end)

 

 

<pre>b="b"</pre>

be switched on and off throughout a source text, and only the symbols

declared when they're on will become visible library entry points.

hidden_variable = 3

 

#library-

 

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

scopes within a single file. In this example, the symbol <code>x</code> will have

a value of 1,

 

#hide+

#hide-

 

but it will be 2 in this example, where

the <code>#export</code> directive selectively allows an otherwise

hidden declaration to be visible outside its enclosing

scope, and allows name clashes to be resolved by proximity.

 

#hide+

#hide-

 

The <code>#hide</code> directives can be arbitrarily nested in matched pairs

to create block structured scope, but doing so is likely to be

declaration. However, this behavior can be overridden using

the dash operator as shown.

 

cat = 3

Here, <code>std-cat</code> refers to the concatenation function from the standard

library, not the locally declared constant by that name.

 

=={{header|zkl}}==