Name resolution (programming languages): Difference between revisions

Revision as of 23:43, 12 October 2016

Latest revision as of 10:11, 24 May 2024

(21 intermediate revisions by 15 users not shown)

Line 1:

{{Short description|Matching of lexical tokens to the components of a computer program}}

{{see also|Name resolution (computer systems)}}

In [[programming language]]s, '''name resolution''' refers tois the resolution of the tokens[[lexical analysis|token]]s within program expressions to the intended program components.

{{merge|Name binding|discuss=Talk:Name binding#Merge Name binding with Name resolution|date=April 2014}}

In [[programming language]]s, '''name resolution''' refers to the resolution of the tokens within program expressions to the intended program components.

==Overview==

Line 16:

In [[programming language]]s, name resolution can be performed either at [[compile time]] or at [[Run time (program lifecycle phase)|runtime]]. The former is called '''static name resolution''', the latter is called '''dynamic name resolution'''.

A somewhat common misconception is that [[dynamic typing]] implies dynamic name resolution. However, static typing does imply static name resolution. For example, [[Erlang (programming language)|Erlang]] is dynamically typed but has static name resolution. However, static typing does imply static name resolution.

Static name resolution catches, at compile time, use of variables that are not in scope; preventing programmer errors. Languages with dynamic scope resolution sacrifice this safety for more flexibility; they can typically set and get variables in the same scope at runtime.

For example, in the [[Python (programming language)|Python]] interactive [[REPL]]:

<sourcesyntaxhighlight lang="pycon">

>>> number = 99

>>> locals()['num'] = 999 # equivalent to: num = 999

>>> nounfirst_noun = "troublesproblems"

>>> noun2second_noun = "hound"

>>> # whichWhich variables to use are decided at runtime

>>> print(f"I got {numnumber} {nounfirst_noun} andbut a {noun2second_noun} ain't one".format(**locals())")

999I troublesgot and99 problems but a hound ain't one.

</syntaxhighlight>

</source>

However, relying on dynamic name resolution in code is discouraged by the Python community.<ref>{{cite web|url=http://mail.python.org/pipermail/python-ideas/2009-May/004582.html|title=<nowiki>[</nowiki>Python-Ideas<nowiki>]</nowiki> str.format utility function|date=9 May 2009|accessdateaccess-date=2011-01-23}}</ref><ref>{{cite web|url=http://diveintopython.org/html_processing/dictionary_based_string_formatting.html|title=8.6. Dictionary-based string formatting|work=diveintopython.org|publisher=Mark Pilgrim|accessdateaccess-date=2011-01-23}}</ref> The feature also may be removed in a later version of Python.<ref>{{cite web |url=https://docs.python.org/3/tutorial/classes.html#python-scopes-and-namespaces|title=9. Classes - Python v2.7.1 documentation |quote=It is important to realize that scopes are determined textually: the global scope of a function defined in a module is that module’s namespace, no matter from where or by what alias the function is called. On the other hand, the actual search for names is done dynamically, at run time — however, the language definition is evolving towards static name resolution, at "compile" time, so don’t rely on dynamic name resolution! (In fact, local variables are already determined statically.)|accessdateaccess-date=20112019-0107-2324}}</ref>

Examples of languages that use static name resolution include [[C (programming language)|C]], [[C++]], [[E (programming language)|E]], [[Erlang (programming language)|Erlang]], [[Haskell (programming language)|Haskell]], [[Java (programming language)|Java]], [[Pascal (programming language)|Pascal]], [[Scheme (programming language)|Scheme]], and [[Smalltalk]]. Examples of languages that use dynamic name resolution include some [[Lisp (programming language)|Lisp]] dialects, [[Perl]], [[PHP]], [[Python (programming language)|Python]], [[REBOLRebol]], and [[Tcl]].

==Name masking==

Line 40:

The outer variable X is said to be ''shadowed'' by the inner variable X'.

For example, the parameter x"foo" masksshadows the local variable "foo" in this common pattern:

<sourcesyntaxhighlight lang="java">

private int foo; // A declaration with nameName "foo" is declared in anthe outer scope

public void setFoo(int foo) { // A declaration with the same name in the inner scope

// "foo" is resolved by looking in the innermost scope first,

// so the author uses a different syntax, this.foo, to refer to the name "foo"

// in the outer scope.

this.foo = foo;

}

// "foo" here means the same as this.foo below,

// since setFoo's parameter is no longer in scope.

public int getFoo() { return foo; }

</source>

public void setFoo(int foo) { // AName declaration"foo" withis the same namedeclared in the inner scope, and is function-local.

this.foo = foo; // Since "foo" will be first found (and resolved) in the ''innermost'' scope,

// in order to successfully overwrite the stored value of the attribute "foo"

// with the new value of the incoming parameter "foo", a distinction is made

// between "this.foo" (the object attribute) and "foo" (the function parameter).

}

public int getFoo() { return foo; }

this.foo =return foo;

}

</syntaxhighlight>

Name masking can cause [[Function overloading#Complications|complications in function overloading]], due to overloading not happening across scopes in some languages, notably C++, thus requiring all overloaded functions to be redeclared or explicitly imported into a given namespace.

==Alpha renaming to make name resolution trivial==

In programming languages with [[lexical scoping]] that do not [[reflectionReflective (computer science)programming|reflect]] over variable names, [[Lambda calculus#.CE.B1-conversion|α-conversion]] (or α-renaming) can be used to make name resolution easy by finding a substitution that makes sure that no variable name [[variable shadowing|masks]] another name in a containing scope. Alpha-renaming can make [[static code analysis]] easier since only the alpha renamer needs to understand the language's scoping rules.

Alpha-renaming can make [[static code analysis]] easier since only the alpha renamer needs to understand the language's scoping rules.

For example, in this code:

<sourcesyntaxhighlight lang="cpp">

class Point {

private:

double x, y;

public:

Point(double x, double y) { // x and y declared here mask the privates

setX(x);

setY(y);

}

public:

void setX(double newx) { x = newx; }

Point(double x, void setY(double newyy) { // x and y =declared here mask newy;the }privates

setX(x);

setY(y);

}

</source>

within the <tt>Point</tt> constructor, the class variables <tt>x</tt> and <tt>y</tt> are [[Variable shadowing|shadowed]] by local variables of the same name. This might be alpha-renamed to:

<source lang="cpp">

class Point {

private:

double x, y;

void setX(double newx) { x = newx; }

public:

void PointsetY(double a, double bnewy) { y = newy; }

}

setX(a);

</syntaxhighlight>

setY(b);

within the <tt>{{mono|Point</tt>}} constructor, the class[[instance variablesvariable]]s <tt>{{mono|x</tt>}} and <tt>{{mono|y</tt>}} are [[Variable shadowing|shadowed]] by local variables of the same name. This might be alpha-renamed to:

}

<sourcesyntaxhighlight lang="cpp">

class Point {

private:

double x, y;

public:

void setX(double newx) { x = newx; }

Point(double a, void setY(double newyb) { y = newy; }

setX(a);

setY(b);

}

</source>

void setX(double newx) { x = newx; }

void setY(double newy) { y = newy; }

}

</syntaxhighlight>

In the new version, there is no masking, so it is immediately obvious which uses correspond to which declarations.