Scope modifiers: Difference between revisions

Content added Content deleted
(add actual →‎Pascal: example)
Line 29: Line 29:
N : constant T := (Component => 0); -- Constant implementation
N : constant T := (Component => 0); -- Constant implementation
end P;</lang>
end P;</lang>

===Bodies (invisible declarations)===
===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 keyword '''body''' applied to the packages, protected objects and tasks. It specifies an implementation of the corresponding entity invisible from anywhere else:
Line 85: Line 86:


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

==={{header|Applesoft BASIC}}===
==={{header|Applesoft BASIC}}===
All variables are global by default, except the parameter which is local to the function. There are no scope modifiers.
All variables are global by default, except the parameter which is local to the function. There are no scope modifiers.
Line 355: Line 355:


=={{header|Common Lisp}}==
=={{header|Common Lisp}}==

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


Line 387: Line 386:
<lang Delphi>private</lang>
<lang Delphi>private</lang>
Can only be seen inside declared class.
Can only be seen inside declared class.



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



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



<lang Delphi>protected</lang>
<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.
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>
<lang Delphi>automated</lang>
Same visibility as Public, and used for Automation Objects. This is currently only maintained for backward compatibility.
Same visibility as Public, and used for Automation Objects. This is currently only maintained for backward compatibility.



<lang Delphi>strict private
<lang Delphi>strict private
strict protected</lang>
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.
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}}==
=={{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.
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.
Line 462: Line 457:


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


Line 494: Line 488:
** exception error: undefined function a_module:add/2
** exception error: undefined function a_module:add/2
</pre>
</pre>

=={{header|Free Pascal}}==
''See [[#Pascal|Pascal]]''


=={{header|Go}}==
=={{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".
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}}==
=={{header|Haskell}}==

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


Line 534: Line 529:


=={{header|J}}==
=={{header|J}}==

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


Line 597: Line 591:


=={{header|JavaScript}}==
=={{header|JavaScript}}==

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


Line 937: Line 930:


=={{header|Pascal}}==
=={{header|Pascal}}==
Pascal does not have scope modifiers.
See [[Scope_modifiers#Delphi | Delphi]]
Regular block scopes are defined simply by virtue of the declaration’s position:
<lang pascal>procedure super;
var
f: boolean;
procedure nestedProcedure;
var
c: char;
begin
// here, `f`, `c`, `nestedProcedure` and `super` are available
end;
procedure commonTask;
var
f: boolean;
begin
// here, `super`, `commonTask` and _only_ the _local_ `f` is available
end;
var
c: char;

procedure fooBar;
begin
// here, `super`, `fooBar`, `f` and `c` are available
end;
var
x: integer;
begin
// here, `c`, `f`, and `x`, as well as,
// `nestedProcedure`, `commonTask` and `fooBar` are available
end;</lang>


=={{header|Perl}}==
=={{header|Perl}}==
Line 1,083: Line 1,106:


===Scope===
===Scope===

In PicoLisp, the scope type of a symbol is either "internal", "transient" or
In PicoLisp, the scope type of a symbol is either "internal", "transient" or
"external".
"external".
Line 1,098: Line 1,120:


===Binding===
===Binding===

Regardless of the scope, the binding of symbols to values is always dynamic.
Regardless of the scope, the binding of symbols to values is always dynamic.
This happens implicitly for function parameters, or explicitly with functions
This happens implicitly for function parameters, or explicitly with functions
Line 1,119: Line 1,140:
}</lang>
}</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.
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}}==
=={{header|PureBasic}}==
* Functions must be defined before being used and are always global in scope.
* Functions must be defined before being used and are always global in scope.
Line 1,201: Line 1,223:
scoped_notdefinedlocally scope gives x = From global scope
scoped_notdefinedlocally scope gives x = From global scope
>>></lang>
>>></lang>
More information on the scope modifiers can be found [http://docs.python.org/3.0/reference/simple_stmts.html#grammar-token-global_stmt here].<br>
More information on the scope modifiers can be found [http://docs.python.org/3.0/reference/simple_stmts.html#grammar-token-global_stmt here].


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


Line 1,313: Line 1,334:


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


Line 1,355: Line 1,375:
d = 55555555
d = 55555555
return /*compliments to Jules Verne's Captain Nemo? */</lang>
return /*compliments to Jules Verne's Captain Nemo? */</lang>

===version 2 scope is DYNAMIC===
===version 2 scope is DYNAMIC===
<lang rexx>a=1
<lang rexx>a=1
Line 1,394: Line 1,415:


===Methods===
===Methods===

Instance methods may be public, private or protected<br>
Instance methods may be public, private or protected<br>
A public method is visible and usable inside and outside an instance.<br>
A public method is visible and usable inside and outside an instance.<br>
Line 1,457: Line 1,477:
===Commands===
===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.
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===
===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.
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.
Line 1,496: Line 1,517:


=={{header|TI-89 BASIC}}==
=={{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).
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).


Line 1,504: Line 1,524:


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