範囲（コンピュータサイエンス）

コンピュータ プログラミングにおいて、名前のバインディング(名前と変数などのエンティティとの関連付け)のスコープとは、名前のバインディングが有効なプログラムの部分、つまり、名前を使用してエンティティを参照できる部分のことです。プログラムの他の部分では、名前は別のエンティティを参照する (別のバインディングがある) か、何も参照しない (バインドされていない) 場合があります。スコープは、名前が別のスコープを持っている限り、同じ名前で異なるオブジェクトを参照できるようにすることで、名前の衝突を防ぐのに役立ちます。名前のバインディングのスコープは、特に古い文献や技術的な文献では、エンティティの可視性とも呼ばれます。これは、参照元の名前ではなく、参照先のエンティティに関連しています。

「スコープ」という用語は、プログラムの一部またはプログラム内の特定のポイントで有効なすべての名前バインディングのセットを指すためにも使用され、より正確にはコンテキストまたは環境と呼ばれます。^[a]

厳密に言えば^[b]、そして実際にはほとんどのプログラミング言語では、「プログラムの一部」はソースコードの一部（テキストの領域）を指し、レキシカルスコープと呼ばれます。ただし、一部の言語では、「プログラムの一部」は実行時間の一部（実行中の期間）を指し、動的スコープと呼ばれます。これらの用語は両方とも多少誤解を招きやすく、定義で説明したように技術用語を誤用していますが、区別自体は正確で明確であり、これらはそれぞれの標準的な用語です。レキシカルスコープがこの記事の主な焦点であり、動的スコープはレキシカルスコープとの対比によって理解されます。

ほとんどの場合、レキシカル スコープに基づく名前解決は、使用と実装が比較的簡単です。使用時には、ソース コードを逆方向に読み取って名前が参照するエンティティを判断でき、実装時には、プログラムをコンパイルまたは解釈するときに名前とコンテキストのリストを維持できます。名前のマスキング、前方宣言、巻き上げでは困難が生じますが、非ローカル変数、特にクロージャでは、かなり微妙な困難が生じます。

名前 (識別子) の (語彙の)「スコープ」の厳密な定義は明確です。語彙のスコープは、「名前とエンティティのバインディングが適用されるソース コードの部分」です。これは、1960 年のALGOL 60仕様の定義から実質的に変更されていません。代表的な言語仕様は次のとおりです。

アルゴル60（1960）^[1]

数量には、単純な変数、配列、ラベル、スイッチ、およびプロシージャがあります。数量のスコープは、その数量に関連付けられた識別子の宣言が有効なステートメントと式の集合です。

C（2007）^[2]

識別子は、オブジェクト、関数、構造体、共用体、列挙体のタグまたはメンバー、typedef名、ラベル名、マクロ名、またはマクロ パラメータを表すことができます。同じ識別子が、プログラム内の異なるポイントで異なるエンティティを表すことができます。[...] 識別子が指定する異なるエンティティごとに、識別子は、スコープと呼ばれるプログラム テキストの領域内でのみ表示されます(つまり、使用できます) 。

囲碁（2013）^[3]

宣言は、空白でない識別子を定数、型、変数、関数、ラベル、またはパッケージにバインドします。 [...] 宣言された識別子のスコープは、指定された定数、型、変数、関数、ラベル、またはパッケージを識別子が示すソース テキストの範囲です。

最も一般的には、「スコープ」は、特定の名前が特定の変数を参照できる場合（宣言が有効な場合）を指しますが、関数、型、クラス、ラベル、定数、列挙体などの他のエンティティにも適用できます。

スコープにおける基本的な違いは、「プログラムの一部」が何を意味するかです。レキシカル スコープ(静的スコープとも呼ばれる) を持つ言語では、名前解決はソース コード内の位置とレキシカル コンテキスト(静的コンテキストとも呼ばれる) に依存します。レキシカル コンテキストは、名前付き変数または関数が定義されている場所によって定義されます。対照的に、動的スコープを持つ言語では、名前解決は、実行コンテキスト(ランタイム コンテキスト、呼び出しコンテキスト、動的コンテキストとも呼ばれる)によって決定される、名前に遭遇したときのプログラムの状態に依存します。実際には、レキシカル スコープでは、名前はローカル レキシカル コンテキストを検索して解決され、それが失敗した場合は外側のレキシカル コンテキストを検索するというように続きます。一方、動的スコープでは、名前はローカル実行コンテキストを検索して解決され、それが失敗した場合は外側の実行コンテキストを検索するというように、呼び出しスタックを上っていきます。^[4]

現代の言語のほとんどは、変数と関数にレキシカル スコープを使用しますが、一部の言語、特に Lisp の一部の方言、一部の「スクリプト」言語、一部のテンプレート言語では動的スコープが使用されます。^[c] Perl 5 はレキシカル スコープと動的スコープの両方を提供します。レキシカル スコープの言語であっても、クロージャのスコープは初心者にとって混乱を招く可能性があります^{[要出典]。}これは、クロージャが呼び出される場所ではなく、クロージャが定義されているレキシカル コンテキストに依存するためです。

字句解決はコンパイル時に決定できるため、早期バインディングとも呼ばれます。一方、動的解決は一般に実行時にのみ決定できるため、遅延バインディングとも呼ばれます。

オブジェクト指向プログラミングでは、動的ディスパッチは実行時にオブジェクトメソッドを選択しますが、実際の名前のバインドがコンパイル時に行われるか実行時に行われるかは言語によって異なります。事実上の動的スコープは、名前解決を直接行わずにその場で拡張する マクロ言語で一般的です。

AngularJSのようなプログラミング フレームワークの中には、この記事で使用されているものとはまったく異なる意味で「スコープ」という用語を使用するものもあります。これらのフレームワークでは、スコープは、使用するプログラミング言語 ( AngularJS の場合はJavaScript ) のオブジェクトにすぎず、フレームワークは、変数にレキシカル スコープを使用する言語で動的スコープをエミュレートするために、特定の方法でスコープを使用します。これらのAngularJS スコープは、他のオブジェクトと同様に言語の変数スコープの通常のルールに従い、独自の継承およびトランスクルージョン ルールを使用して、プログラムの任意の部分でコンテキスト内またはコンテキスト外になることができます (用語の通常の意味を使用)。AngularJS のコンテキストでは、混乱を避けるために「$scope」(ドル記号付き) という用語が使用されることがありますが、変数名にドル記号を使用することは、スタイル ガイドによって推奨されないことがよくあります。^[5]

スコープは名前解決の重要な要素であり、^[d]言語セマンティクスの基礎となります。名前解決 (スコープを含む) はプログラミング言語によって異なり、プログラミング言語内でもエンティティの種類によって異なります。スコープのルールはスコープ ルール(またはスコープ設定ルール) と呼ばれます。名前空間とともに、スコープ ルールはモジュール プログラミングにおいて非常に重要であり、プログラムの一部を変更しても無関係な部分が壊れることはありません。

スコープについて議論する場合、スコープ、 範囲、コンテキストという 3 つの基本概念があります。特に「スコープ」と「コンテキスト」はよく混同されます。スコープは名前バインディングのプロパティですが、コンテキストはプログラムの一部、つまりソース コードの一部 (レキシカル コンテキストまたは静的コンテキスト) または実行時の一部(実行コンテキスト、 ランタイム コンテキスト、 呼び出しコンテキストまたは動的コンテキスト) のプロパティです。実行コンテキストは、レキシカル コンテキスト (現在の実行ポイント) と、コール スタックなどの追加のランタイム状態で構成されます。^[e]厳密に言えば、実行中にプログラムはさまざまな名前バインディングのスコープに出入りし、実行中のある時点で名前バインディングは「コンテキスト内」または「コンテキスト外」になります。したがって、プログラム実行がスコープに出入りすると、名前バインディングは「コンテキストに入る」か「コンテキストから出る」ことになります。^[f]ただし、実際には使用法ははるかに緩やかです。

スコープはソースコード レベルの概念であり、名前のバインディング、特に変数または関数の名前のバインディングの特性です。ソースコード内の名前はプログラム内のエンティティへの参照であり、言語のコンパイラまたはインタープリタの動作の一部です。そのため、スコープの問題は、より一般的にプログラムで使用される参照の一種であるポインターに似ています。名前がコンテキスト内にあるが変数が初期化されていない場合に変数の値を使用することは、ワイルド ポインターが未定義であるため、その逆参照 (値へのアクセス) に似ています。ただし、変数はコンテキストから外れるまで破棄されないため、ダングリング ポインターに類似するものは存在しません。

変数などのエンティティの場合、スコープはライフタイム(エクステントとも呼ばれる)のサブセットです。名前は存在する変数 (未定義の値の可能性もあります) のみを参照できますが、存在する変数は必ずしも可視であるとは限りません。変数は存在していてもアクセスできない (値は格納されているが特定のコンテキスト内で参照されていない) 場合や、アクセス可能であっても特定の名前経由ではアクセスできない場合があり、その場合、変数はコンテキスト内にありません (プログラムは「名前のスコープ外」にあります)。その他の場合、「ライフタイム」は無関係です。ラベル (ソース コード内の名前付き位置) のライフタイムはプログラムと同じですが (静的にコンパイルされた言語の場合)、プログラム内の特定の時点でコンテキスト内にある場合とそうでない場合があります。静的変数についても同様です。静的グローバル変数はプログラム全体のコンテキスト内にありますが、静的ローカル変数は関数またはその他のローカル コンテキスト内のみのコンテキスト内にありますが、どちらもプログラムの実行全体がライフタイムとなります。

名前が参照するエンティティを決定することは、名前解決または名前バインディング(特にオブジェクト指向プログラミング)と呼ばれ、言語によって異なります。名前が指定されると、言語 (正確にはコンパイラまたはインタープリタ) はコンテキスト内のすべてのエンティティをチェックして一致を探します。あいまいな場合 (同じ名前のグローバル変数とローカル変数など、同じ名前のエンティティが 2 つある場合) は、名前解決ルールを使用してそれらを区別します。最も頻繁に使用される名前解決は、Python LEGB (Local、Enclosing、Global、Built-in) ルールなどの「内部から外部へのコンテキスト」ルールに依存します。つまり、名前は暗黙的に最も狭い関連コンテキストに解決されます。場合によっては、 Python のglobalおよびnonlocalキーワードによって名前解決を明示的に指定できますが、デフォルトのルールをオーバーライドできない場合もあります。

2 つの同一の名前が同時にコンテキスト内に存在し、異なるエンティティを参照している場合、名前のマスキングが発生していると言われます。つまり、優先順位の高い名前 (通常は最も内側の名前) が優先順位の低い名前を「マスキング」していることになります。変数レベルでは、これは変数シャドウイングと呼ばれます。マスキングによる論理エラーの可能性があるため、一部の言語では、コンパイル時または実行時にエラーまたは警告が発生し、マスキングが禁止または推奨されていません。

さまざまなプログラミング言語には、さまざまな種類の宣言と名前に対してさまざまなスコープ ルールがあります。このようなスコープ ルールは言語のセマンティクスに大きな影響を与え、結果としてプログラムの動作と正確性に影響します。C ++などの言語では、バインドされていない変数へのアクセスには明確に定義されたセマンティクスがなく、ぶら下がりポインターを参照するのと同様に、未定義の動作が発生する可能性があります。また、スコープ外で使用される宣言または名前は構文エラーを生成します。

スコープは他の言語構成要素に結び付けられ、暗黙的に決定されることがよくありますが、多くの言語ではスコープを制御するための構成要素も提供されています。

スコープは、単一の式からプログラム全体までさまざまで、その間にはさまざまな段階があります。最も単純なスコープ規則はグローバル スコープです。つまり、すべてのエンティティがプログラム全体で可視です。最も基本的なモジュラー スコープ規則は 2 レベルのスコープで、グローバル スコープはプログラム内の任意の場所に存在し、ローカル スコープは関数内にあります。より洗練されたモジュラー プログラミングでは、別のモジュール スコープを使用できます。この場合、名前はモジュール内では可視ですが (モジュールに対してプライベート)、モジュール外では可視ではありません。関数内では、C などの一部の言語では、ブロック スコープを使用して、スコープを関数のサブセットに制限できます。他の言語 (特に関数型言語) では、式スコープを使用して、スコープを単一の式に制限できます。その他のスコープには、モジュール スコープと同様に動作するファイル スコープ (特に C) や、関数外のブロック スコープ (特に Perl) があります。

微妙な問題は、スコープが正確にいつ始まり、いつ終わるかということです。C などの一部の言語では、名前のスコープは名前の宣言から始まるため、特定のブロック内で宣言された異なる名前は異なるスコープを持つことができます。このため、関数を使用する前に宣言する必要がありますが、必ずしも定義する必要はありません。また、相互再帰の場合は特に、前方宣言が必要になる場合があります。Python などの他の言語では、名前のスコープは、名前が定義されている場所に関係なく、名前が宣言されている関連ブロック (関数の開始など) の開始から始まるため、特定のブロック内のすべての名前は同じスコープを持ちます。JavaScript では、letまたはで宣言された名前のスコープはconst名前の宣言から始まり、で宣言された名前のスコープは、名前varが宣言されている関数の開始から始まります。これは、変数巻き上げと呼ばれます。コンテキスト内で未定義の値を持つ名前の動作は異なります。Python では未定義の名前を使用すると実行時エラーが発生しますが、JavaScript では、で宣言された未定義の名前は、var値に暗黙的にバインドされるため、関数全体で使用できますundefined。

名前バインディングのスコープは式 で、これは式スコープとして知られています。式スコープは多くの言語、特に関数型言語で使用できます。関数型言語では、 let 式と呼ばれる機能が提供されており、宣言のスコープを単一の式にすることができます。これは、たとえば、計算に中間値が必要な場合に便利です。たとえば、Standard MLでは、f()が を返す場合12、 はに評価される式であり、2 回の呼び出しを回避するためにという名前の一時変数が使用されます。ブロック スコープを持つ一部の言語では、ブロックを式に埋め込む構文を提供することで、この機能に近似しています。たとえば、前述の Standard ML 式は、 Perlでは、GNU Cではと記述できます。 let val x = f() in x * x end144xf()do { my $x = f(); $x * $x }({ int x = f(); x * x; })

Python では、ジェネレータ式とリスト内包表記 (Python 3) の補助変数には式スコープがあります。

C では、関数プロトタイプ内の変数名には式スコープがあり、このコンテキストでは関数プロトコル スコープと呼ばれます。プロトタイプ内の変数名は参照されないため (実際の定義では異なる場合があります)、ダミーに過ぎず、多くの場合省略されますが、たとえばドキュメントの生成に使用されることがあります。

名前バインディングのスコープはブロックであり、ブロック スコープと呼ばれます。ブロック スコープは、多くのブロック構造プログラミング言語で使用できますが、すべてではありません。これはALGOL 60から始まり、「すべての宣言は...そのブロックに対してのみ有効です。」^[6] 。今日では特にPascalおよびCファミリーと伝統の言語に関連付けられています。ほとんどの場合、このブロックは関数内に含まれるため、スコープは関数の一部に制限されますが、Perl などの一部のケースでは、ブロックが関数内にない場合があります。

unsigned int sum_of_squares ( const unsigned int N ) { unsigned int ret = 0 ; for ( unsigned int n = 1 ; n <= N ; n ++ ) { const unsigned int n_squared = n * n ; ret += n_squared ; } return ret ; }      
      
            
           
      
  
   

ブロック スコープの使用の代表的な例は、ここに示す C コードです。ここでは、2 つの変数のスコープがループに設定されています。1つは、ループの各反復で一度初期化されて増分されるループ変数n 、もう 1 つは各反復で初期化される補助変数n_squared です。目的は、特定のブロックにのみ関連する変数を関数スコープに追加しないようにすることです。たとえば、これにより、汎用ループ変数iが誤って別の値に設定されているというエラーを防止できます。この例では、式はn * n通常、補助変数に割り当てられず、ループの本体は単純に記述されますret += n * nが、より複雑な例では補助変数が役立ちます。

ブロックは主に、if、while、for ループなどの制御フローに使用されます。この場合、ブロック スコープとは、変数のスコープが関数の実行フローの構造に依存することを意味します。ただし、ブロック スコープを持つ言語では通常、変数のスコープを細かく制御することだけを目的とした「ネイキッド」ブロックの使用も許可されます。たとえば、補助変数をブロックで定義し、使用して (関数スコープを持つ変数に追加するなど)、ブロックの終了時に破棄したり、while ループを、ループ内で使用され、一度だけ初期化する必要がある変数を初期化するブロックで囲んだりすることができます。

Algol 68や C (この例で示され、C99以降標準化されている)などのいくつかのプログラミング言語の微妙な点は、ブロックスコープ変数をブロックの本体内だけでなく、制御文 (存在する場合) 内でも宣言できることです。これは、関数宣言 (関数本体のブロックが始まる前) で宣言され、関数本体全体のスコープ内にある関数パラメータに似ています。これは主にfor ループで使用されます。for ループにはwhile ループとは異なり、ループ条件とは別に初期化文があり、一般的なイディオムです。

ブロック スコープはシャドウイングに使用できます。この例では、ブロック内で補助変数をnと呼び、パラメータ名をシャドウイングすることもできますが、これはエラーの可能性があるため、不適切なスタイルと見なされます。さらに、Java や C# などの C の派生言語では、ブロック スコープ (関数の終了前にローカル変数をコンテキスト外にすることができる) がサポートされているにもかかわらず、1 つのローカル変数が別のローカル変数を隠すことはできません。このような言語では、2 番目のn を宣言しようとすると構文エラーが発生し、n 個の変数の 1 つを名前変更する必要があります。

ブロックを使用して変数の値を設定する場合、ブロック スコープでは、変数をブロックの外で宣言する必要があります。これにより、単一の割り当てを含む条件文の使用が複雑になります。たとえば、ブロック スコープを使用しない Python では、次のように変数を初期化できます。

 c の場合: 
    a  =  "foo" 
、そうでない場合: 
    a  =  ""

aステートメントの後にアクセスできる場所if。

ブロック スコープを持つ Perl では、代わりにブロックの前に変数を宣言する必要があります。

私の$a ; if ( c ) { $a = 'foo' ; } else { $a = '' ; } 
  
      
  
      

多くの場合、代わりに多重代入を使用してこれを書き換え、変数をデフォルト値に初期化します。Python では (必要ない場合) 次のようになります。

a  =  "" の
場合 c : 
    a  =  "foo"

Perl では次のようになります。

私の$a = '' ; if ( c ) { $a = 'foo' ; }   
  
      

単一の変数割り当ての場合、ブロックを回避するために三項演算子を使用するという選択肢もありますが、これは一般に複数の変数割り当てでは不可能であり、複雑なロジックでは読みにくくなります。

これは C ではより重大な問題であり、特に文字列の割り当ての場合に顕著です。文字列の初期化ではメモリを自動的に割り当てることができますが、すでに初期化された変数への文字列の割り当てでは、メモリの割り当て、文字列のコピー、およびこれらが成功したかどうかのチェックが必要になるためです。

{ 
my $counter = 0 ; sub increment_counter { return ++ $counter ; } }     
    
        
  

一部の言語では、ブロック スコープの概念を関数の外部にさまざまな範囲で適用できます。たとえば、右の Perl スニペットでは、 は$counterブロック スコープを持つ変数名 (キーワードの使用によるmy) ですが、 はincrement_counterグローバル スコープを持つ関数名です。 を呼び出すたびにincrement_counterの値が$counter1 ずつ増加し、新しい値を返します。このブロックの外側のコードは を呼び出すことはできますincrement_counterが、 の値を取得または変更することはできません$counter。このイディオムにより、Perl でクロージャを定義できます。

関数内で宣言された変数のスコープがその関数を超えて拡張されない場合、これは関数スコープと呼ばれます。^[7]関数スコープは、関数またはサブルーチン内でローカル変数を作成する方法を提供するほとんどのプログラミング言語で使用できます。ローカル変数とは、関数が返されるときにスコープが終了する（コンテキストから外れる）変数です。ほとんどの場合、変数の有効期間は関数呼び出しの期間です。つまり、関数の開始時（または変数の宣言時）に作成され、関数が返されるときに破棄される自動変数です。一方、変数のスコープは関数内ですが、「内」の意味はスコープがレキシカルか動的かによって異なります。ただし、C などの一部の言語では、静的ローカル変数も提供されており、変数の有効期間はプログラムの存続期間全体ですが、変数は関数内にある場合にのみコンテキスト内にあります。静的ローカル変数の場合、変数はプログラムの初期化時に作成され、静的グローバル変数と同様にプログラムが終了したときにのみ破棄されますが、自動ローカル変数と同様に関数内のみでコンテキスト内にあります。

重要なのは、レキシカル スコープでは、関数スコープを持つ変数のスコープは関数のレキシカル コンテキスト内でのみであるということです。つまり、関数内で別の関数が呼び出されると変数はコンテキストから外れ、関数が返されるとコンテキストに戻ります。呼び出された関数は呼び出し元の関数のローカル変数にアクセスできず、ローカル変数は宣言されている関数の本体内でのみコンテキスト内にあります。対照的に、動的スコープでは、スコープは関数の実行コンテキストまで拡張されます。ローカル変数は別の関数が呼び出されてもコンテキスト内にとどまり、定義関数が終了したときにのみコンテキストから外れるため、ローカル変数は定義されている関数とすべての呼び出された関数のコンテキスト内にあります。レキシカル スコープとネストされた関数を持つ言語では、ネストされた関数は同じレキシカル コンテキスト内にあるため、ローカル変数はコンテキスト内にありますが、レキシカルにネストされていない他の関数の場合はそうではありません。外側の関数のローカル変数は、ネストされた関数の非ローカル変数と呼ばれます。関数スコープは匿名関数にも適用できます。

def  square ( n ): 
    n * n を返す   

def  sum_of_squares ( n ): 
    total  =  0  
    i  =  0 
    while  i  <=  n : 
        total  +=  square ( i ) 
        i  +=  1
    合計を返す 

たとえば、右側の Python コード スニペットでは、squareと のsum_of_squares2つの関数が定義されています。squareは数値の平方を計算し、はsum_of_squares数値までのすべての平方の合計を計算します。 (たとえば、square(4)は 4 ²  = であり16、sum_of_squares(4)は 0 ²  + 1 ²  + 2 ²  + 3 ²  + 4 ²  = です30。)

これらの関数にはそれぞれ、関数の引数を表すnという名前の変数があります。これら 2 つのn変数は同じ名前ですが、完全に別個で無関係です。これは、関数スコープを持つレキシカル スコープのローカル変数であるためです。各変数のスコープは、レキシカルに独立した独自の関数であるため、重複しません。したがって、 は自身のn を変更することなくsum_of_squares呼び出すことができます。同様に、 にはtotalおよびiという名前の変数があります。これらの変数はスコープが限定されているため、他の関数に属する可能性のあるtotalまたはiという名前の変数に干渉しません。つまり、これらの名前と無関係な名前が同一であっても、 名前が衝突するリスクはありません。squaresum_of_squares

名前のマスキングは発生しません。スコープが重複しないため、コンテキスト内にはnという名前の変数が常に 1 つだけ存在します。対照的に、同様のフラグメントが動的スコープを持つ言語で記述された場合、呼び出し関数のn は呼び出される関数のコンテキスト内に残り (スコープが重複します)、呼び出される関数の 新しいnによってマスク (「シャドウ化」) されます。

関数がファーストクラス オブジェクトであり、関数に対してローカルに作成されてから返される場合、関数スコープは大幅に複雑になります。この場合、ネストされた関数内のローカルではない変数 (関数定義内のバインドされていない変数で、囲まれたコンテキスト内の変数に解決されるもの) は、関数自体だけでなく、そのコンテキスト (変数) も返され、その後、別のコンテキストで呼び出される可能性があるため、クロージャを作成します。これにより、コンパイラからのサポートが大幅に増加し、プログラム分析が複雑になる可能性があります。

名前バインディングのスコープはファイルであり、これはファイル スコープと呼ばれます。ファイル スコープは主に C (および C++) に特有のもので、ファイルの最上位レベル (関数内ではない) で宣言された変数と関数のスコープはファイル全体、または C の場合は宣言からソース ファイルの終わりまで、より正確には翻訳単位(内部リンク) までです。これはモジュール スコープの一種と見なすことができ、モジュールはファイルで識別され、より新しい言語では明示的なモジュール スコープに置き換えられています。変数と関数を内部コンテキストに追加し、それ自体がさらに include ステートメントを呼び出す可能性のある include ステートメントがあるため、ファイル本体のコンテキスト内の内容を判断するのが困難な場合があります。

上記の C コード スニペットでは、関数名にsum_of_squaresグローバル スコープ (C では extern リンケージ) があります。static関数シグネチャに追加すると、ファイル スコープ (内部リンケージ) になります。

名前バインディングのスコープはモジュールであり、モジュール スコープと呼ばれます。モジュール スコープは、モジュール (さまざまなファイルにまたがる場合があります) が複雑なプログラムの基本単位であるモジュラー プログラミング言語で使用できます。モジュール スコープによって、情報の隠蔽と限定されたインターフェイスの公開が可能になります。モジュール スコープはModulaファミリーの言語で開拓され、Python (Modula の影響を受けています) は、現代の代表的な例です。

C++20 より前の C++ など、モジュールを直接サポートしていないオブジェクト指向プログラミング言語の中には、 ^[8]代わりにクラス階層によって同様の構造が提供され、クラスがプログラムの基本単位となり、クラスがプライベート メソッドを持つことができるものがあります。これは、名前解決やスコープではなく、動的ディスパッチのコンテキストで適切に理解されますが、これらはしばしば類似した役割を果たします。モジュールとクラスの両方を持つ Python のように、これらの両方の機能が利用できる場合もあり、コードの構成 (モジュール レベルの関数として、または従来のプライベート メソッドとして) はプログラマーの選択です。

名前バインディングのスコープはプログラム全体であり、これはグローバル スコープと呼ばれます。グローバル スコープを持つ変数名 (グローバル変数と呼ばれます) は、名前の衝突や意図しないマスキングの可能性、およびモジュール性の低さから、少なくとも一部の言語ではよく悪い習慣とみなされ、関数スコープまたはブロック スコープが望ましいと考えられています。ただし、グローバル スコープは通常 (言語によって異なりますが)、関数名、クラス名、その他のデータ型の名前など、さまざまな種類の名前に使用されます。このような場合、衝突を回避するために 名前空間などのメカニズムが使用されます。

ローカル変数 (特定の関数内にのみ存在する、スコープが限定された変数名) を使用すると、同じ名前の 2 つの変数間で名前が衝突するリスクを回避できます。ただし、この質問に答えるには 2 つのまったく異なるアプローチがあります。関数「内」にあるとはどういう意味ですか?

レキシカル スコープ(またはレキシカル スコープ。静的スコープまたは静的スコープとも呼ばれる) では、変数名のスコープが特定の関数である場合、そのスコープは関数定義のプログラム テキストです。つまり、そのテキスト内では、変数名が存在し、変数の値にバインドされますが、そのテキストの外側では、変数名は存在しません。対照的に、動的スコープ(または動的スコープ) では、変数名のスコープが特定の関数である場合、そのスコープは関数が実行されている期間です。関数の実行中は、変数名が存在し、その値にバインドされますが、関数が戻った後は、変数名は存在しません。つまり、 function がf別途定義された function を呼び出す場合g、レキシカル スコープでは、 function はのローカル変数にアクセスできgませんf( のテキストgが のテキスト内にないと仮定f)。一方、動的スコープでは、 function はのローカル変数にアクセスできg ます(は の呼び出し中に呼び出されるため)。 fgf

$ # bash 言語
$ x = 1 
$ function  g () { echo $x ; x = 2 ; } $ function f () { local x = 3 ; g ; } $ f # これは 1 と 3 のどちらを出力しますか? 3 $ echo $x # これは 1 と 2 のどちらを出力しますか? 1       
        
 

  

たとえば、右側のプログラムについて考えてみましょう。最初の行 は、グローバル変数を作成し、それを に初期化します。2 行目の は、の現在の値を出力 (「エコー」) し、を に設定する (以前の値を上書きする)関数を定義します。3 行目の は、ローカル変数(同じ名前のグローバル変数を非表示にする) を作成し、それを に初期化し、 を呼び出す関数を定義します。4 行目の は、を呼び出します。5 行目の は、の現在の値を出力します。 x=1x1function g() { echo $x ; x=2 ; }gxx2function f() { local x=3 ; g ; }fx3gffecho $xx

では、このプログラムは正確には何を出力するのでしょうか。それはスコープのルールによって異なります。このプログラムの言語がレキシカル スコープを使用する言語である場合、 はgグローバル変数を出力して変更しますx(gの外部で定義されているためf) 。したがって、プログラムは を出力して1からを出力します。2対照的に、この言語が動的スコープを使用する場合、 はのローカル変数gを出力して変更します(の内部から呼び出されるため) 。したがって、プログラムは を出力してから を出力します。 (偶然にも、このプログラムの言語はBashであり、動的スコープを使用します。したがって、プログラムは を出力してから を出力します。同じコードをレキシカル スコープを使用するksh93で実行した場合、結果は異なります。)fxgf3131

レキシカル スコープでは、名前は常にそのレキシカル コンテキストを参照します。これはプログラム テキストの特性であり、言語実装によってランタイムコール スタックから独立しています。この一致には静的プログラム テキストの分析のみが必要なため、このタイプのスコープは静的スコープとも呼ばれます。レキシカル スコープは、 Pascal、Modula-2、AdaなどのすべてのALGOLベースの言語、およびMLやHaskellなどの最新の関数型言語で標準となっています。また、 C 言語とその構文的および意味的関連でも使用されていますが、さまざまな制限があります。静的スコープにより、プログラマはパラメーター、変数、定数、型、関数などのオブジェクト参照を単純な名前の置換として推論できます。これにより、ローカルな命名構造を単独で理解できるため、モジュール コードを作成して推論することがはるかに簡単になります。対照的に、動的スコープでは、プログラマはモジュールのコードが呼び出される可能性のあるすべての実行コンテキストを予測する必要があります。

プログラムA ;変数I :整数; K :文字; 
 
    

    手順B ; var K :実数; L :整数; 
     
        

        手順C ;変数M : real ;開始(*スコープ A+B+C*)終了; 
         
        
         
        

     (*スコープA+B*)
終了;    

 (*スコープA*)
終了。

たとえば、Pascal はレキシカル スコープです。右の Pascal プログラム フラグメントを検討してください。変数は、I同じ名前の別の変数によって隠されることがないため、すべてのポイントで表示されます。変数charは、プロシージャ内でのみ表示される変数によってK隠されているため、メイン プログラム内でのみ表示されます。変数もプロシージャ内でのみ表示されますが、他の変数を隠すことはありません。変数はプロシージャ内でのみ表示されるため、プロシージャからもメイン プログラムからもアクセスできません。また、プロシージャはプロシージャ内でのみ表示されるため、メイン プログラムから呼び出すことはできません。 realKBCLBCMCBCB

Cプログラムでは、 procedure の外側に別のプロシージャが宣言されている可能性がありますB。プログラム内で " " が記述されている場所によって、それがC表す 2 つのプロシージャが決定されますC。これは、変数のスコープとまったく同じです。

第一級の ネストされた関数を持つ言語でレキシカルスコープを正しく実装することは簡単ではありません。各関数値が、それが依存する変数の値の記録を保持することを必要とするからです (関数とこのコンテキストのペアは クロージャ と呼ばれます) 。実装とコンピュータアーキテクチャによっては、非常に深くレキシカルにネストされた関数を使用すると、変数の検索が 若干非効率になることがあります^[要出典]。ただし、これを軽減するよく知られた手法があります。^{[9] [10]}また、自身の引数と (直接の) ローカル変数のみを参照するネストされた関数の場合、すべての相対位置はコンパイル時に知ることができます。したがって、そのタイプのネストされた関数を使用する場合、オーバーヘッドはまったく発生しません。同じことが、ネストされた関数が使用されていないプログラムの特定の部分にも当てはまります。また、当然ながら、ネストされた関数が利用できない言語 (C 言語など) で書かれたプログラムにも当てはまります。

レキシカルスコープは1960年代初頭に命令型言語ALGOL 60で初めて使用され、それ以来他のほとんどの命令型言語でも採用されてきました。^[4]

PascalやCのような言語は、ALGOL 60やALGOL 68に組み込まれたアイデアの影響を受けているため、常にレキシカル スコープを備えています(ただし、C にはレキシカルにネストされた関数は含まれていません)。

Perl は、後から静的スコープを追加した動的スコープを持つ言語です。

オリジナルのLispインタプリタ (1960) は動的スコープを使用していました。静的 (レキシカル) スコープに近いディープ バインディングは、1962 年頃の LISP 1.5 で導入されました ( John McCarthyの下で働いていたSteve Russellが開発したFunargデバイス経由)。

初期のLisp はすべて、インタープリタをベースとしていたため、動的スコープを使用していました。1982 年に、Guy L. Steele Jr. と Common LISP グループは、An outline of Common LISP ^{[11]を出版しました。これは、Lisp の歴史と、その時点までのさまざまな実装の簡単なレビューと、} Common Lisp の実装に必要な 機能のレビューです。102 ページに、次のように書かれています。

ほとんどの LISP 実装は、デフォルトでインタープリタとコンパイラが正しいプログラムに異なるセマンティクスを割り当てる可能性があるという点で、内部的に一貫性がありません。これは主に、インタープリタがすべての変数が動的スコープであると想定するのに対し、コンパイラは、他のことを強制されない限りすべての変数がローカルであると想定するという事実に起因しています。これは利便性と効率性のために行われていますが、非常に微妙なバグにつながる可能性があります。Common LISP の定義では、インタープリタとコンパイラが正しいプログラムに同一のセマンティクスを適用することを明示的に要求することで、このような異常を回避しています。

したがって、Common LISP の実装には、レキシカル スコープが必要でした。再び、「Common LISP の概要」から引用します。

さらに、Common LISP は以下の機能を提供します (そのほとんどは MacLisp、InterLisp、または Lisp Machines Lisp から借用されています)。(...) 完全にレキシカルスコープの変数。いわゆる「FUNARG 問題」^{[12] [13]}は、下向きの場合と上向きの場合の両方で完全に解決されます。

An Overview of Common LISPが出版されたのと同じ年 (1982 年) には、コンパイルされたレキシカルスコープの Lisp ( Schemeと呼ばれる) の初期設計 (これも Guy L. Steele Jr. による)が出版され、コンパイラ実装が試みられていました。当時、Lisp のレキシカルスコープは実装が非効率的であると一般に懸念されていました。A History of Tで、^[14] Olin Shivers は次のように書いています。

当時、本格的な製品で使用されていた Lisp はすべて動的スコープでした。Rabbit ^{[15]論文 (1978 年に Guy Lewis Steele Jr. によって執筆) を注意深く読んでいなければ、レキシカル スコープがうまくいくとは誰も信じていませんでした。それを読ん}だ少数の人々でさえ、これが本格的な製品での使用で機能するとは思い込んでいました。

「レキシカルスコープ」という用語は少なくとも1967年に遡り、^[16]「レキシカルスコープ」という用語は少なくとも1970年に遡り、プロジェクトMACでLisp方言MDL（当時は「Muddle」と呼ばれていました）のスコープルールを説明するために使用されました。 ^[17]

動的スコープでは、名前は実行コンテキストを参照します。技術的に言えば、これは各名前がバインディングのグローバルスタックを持つことを意味します。名前を持つローカル変数を導入すると、xバインディングがグローバル スタック (空である可能性があります) にプッシュされ、制御フローがスコープを離れるxとポップオフされます。どのコンテキストでも評価すると、常に最上位のバインディングが生成されます。バインディング スタックは実行時にのみ存在するため、コンパイル時にはこれを実行できないことに注意してください。これが、このタイプのスコープが動的スコープ と呼ばれる理由です。x

動的スコープは現代の言語では一般的ではない。^[4]

一般的に、特定のブロックは、ブロックの実行時間を存続期間とするバインディングを作成するように定義されます。これにより、動的スコープ プロセスに静的スコープの一部の機能が追加されます。ただし、コード セクションはさまざまな場所や状況から呼び出される可能性があるため、変数が使用されるときに (または、変数が存在するかどうか)、最初にどのバインディングが適用されるかを判断することが困難な場合があります。これは有益な場合があります。最小知識の原則を適用すると、コードは変数の値の理由(または状況)に依存することを避け、変数の定義に従って値を使用するように指示されます。共有データのこの狭い解釈により、関数の動作をシステムの現在の状態 (またはポリシー) に適応させる非常に柔軟なシステムを提供できます。ただし、この利点は、このように使用されるすべての変数を注意深く文書化し、変数の動作に関する仮定を慎重に回避することに依存しており、プログラムのさまざまな部分間の干渉を検出するメカニズムは提供されません。PerlやCommon Lispなどの一部の言語では、プログラマーが変数を定義または再定義するときに静的スコープまたは動的スコープを選択できます。動的スコープを使用する言語の例としては、Logo、Emacs Lisp、LaTeX、シェル言語のbash、dash、PowerShellなどがあります。

動的スコープの実装はかなり簡単です。名前の値を見つけるために、プログラムは実行時スタックを走査し、各アクティベーション レコード (各関数のスタック フレーム) で名前の値を確認します。実際には、名前と値のペアのスタックである連想リストを使用することで、この処理はより効率的になります。ペアは宣言が行われるたびにこのスタックにプッシュされ、変数がコンテキストから外れるとポップされます。^[18] 浅いバインディングは、それぞれの名前を独自の意味のスタックに関連付ける中央参照テーブルを使用する、かなり高速な代替戦略です。これにより、実行時に特定の名前を見つけるための線形検索を回避できますが、このテーブルを適切に維持するように注意する必要があります。^[18]これらの戦略は両方とも、1 つの変数に対するバインディングに対して後入れ先出し ( LIFO ) 順序を前提としていることに注意してください。実際には、すべてのバインディングがそのように順序付けられます。

さらに単純な実装は、動的変数を単純なグローバル変数で表現することです。ローカル バインディングは、プログラムからは見えないスタック上の匿名の場所に元の値を保存することによって実行されます。そのバインディング スコープが終了すると、元の値がこの場所から復元されます。実際、動的スコープはこのようにして生まれました。Lisp の初期の実装では、ローカル変数を実装するためにこの明白な戦略が使用され、この方法は、GNU Emacs Lisp など、現在も使用されているいくつかの方言に残っています。レキシカル スコープは、後に Lisp に導入されました。これは、中央の参照テーブルが単にグローバル変数バインディング コンテキストであり、変数の現在の意味がそのグローバル値である点を除いて、上記の浅いバインディング スキームに相当します。グローバル変数の維持は複雑ではありません。たとえば、シンボル オブジェクトには、そのグローバル値専用のスロットがあります。

動的スコープは、スレッドローカル ストレージの優れた抽象化を提供しますが、そのように使用する場合は、グローバル変数の保存と復元に基づくことはできません。 考えられる実装戦略は、各変数にスレッドローカル キーを持たせることです。 変数にアクセスすると、スレッドローカル キーを使用してスレッドローカル メモリの場所にアクセスします (コンパイラによって生成されたコードによって、どの変数が動的でどの変数がレキシカルであるかがわかります)。 呼び出しスレッドにスレッドローカル キーが存在しない場合は、グローバルの場所が使用されます。 変数がローカルにバインドされている場合、以前の値はスタック上の非表示の場所に格納されます。 スレッドローカル ストレージは変数のキーの下に作成され、新しい値がそこに格納されます。 そのスレッド内での変数のさらにネストされたオーバーライドは、このスレッドローカルの場所を保存および復元するだけです。 最初の最も外側のオーバーライドのコンテキストが終了すると、スレッドローカル キーが削除され、変数のグローバル バージョンが再びそのスレッドに公開されます。

参照透過性により、動的スコープは現在の関数の引数スタックのみに制限され、レキシカル スコープと一致します。

現代の言語では、プリプロセッサでのマクロ展開は事実上の動的スコープの重要な例です。マクロ言語自体は名前を解決せずにソース コードを変換するだけですが、展開はインプレースで行われるため、展開されたテキスト内の名前 (特に自由変数) が解決されるとき、動的スコープが発生しているかのように、展開された場所 (大まかに「呼び出される」) に基づいて解決されます。

マクロの展開に使用される C プリプロセッサは、それ自体では名前解決を行わず、マクロが定義されている場所に依存しないため、事実上の動的スコープを持ちます。たとえば、次のマクロ:

#define ADD_A(x) x + a

aは、渡された変数に追加するために展開されます。この名前は、マクロADD_Aが「呼び出される」(適切には展開される) 場所に基づいて、後でコンパイラによってのみ解決されます。適切には、C プリプロセッサは語彙解析のみを実行し、トークン化の段階でマクロを展開しますが、構文ツリーに解析したり、名前解決を行ったりはしません。

たとえば、次のコードでは、aマクロ内の名前は (展開後に) 展開サイトのローカル変数に解決されます。

#define ADD_A(x) x + a

void add_one ( int * x ) { const int a = 1 ; * x = ADD_A ( * x ); }   
      
    


void add_two ( int * x ) { const int a = 2 ; * x = ADD_A ( * x ); }   
      
    

これまで見てきたように、スコープの主な理由の 1 つは、名前が別々のスコープを持つ必要があるという制限付きで、同一の名前が異なるものを参照できるようにすることで、名前の衝突を防ぐのに役立つことです。この制限は不便な場合があります。プログラム全体でさまざまなものにアクセスする必要がある場合、通常、それらすべてにグローバル スコープの名前が必要になるため、名前の衝突を回避するにはさまざまな手法が必要になります。

これに対処するため、多くの言語ではグローバル名を編成するメカニズムを提供しています。これらのメカニズムの詳細や使用される用語は言語によって異なりますが、一般的な考え方としては、名前のグループ自体に名前 (プレフィックス) を与えることができ、必要に応じて、名前とプレフィックスで構成される修飾名でエンティティを参照できます。通常、このような名前には、ある意味で 2 セットのスコープがあります。1 つは修飾名が可視であるスコープ (通常はグローバル スコープ) で、もう 1 つは非修飾名(プレフィックスなし) も可視である 1 つ以上の狭いスコープです。通常、これらのグループ自体をグループに編成できます。つまり、ネストできます。

多くの言語がこの概念をサポートしていますが、詳細は大きく異なります。言語によっては、C++やC#の名前空間など、グローバル名をグループに編成できるようにするためだけのメカニズムがあります。他の言語には、 AdaのパッケージやStandard MLの構造体など、これに加えて、一部の名前をそのグループの他のメンバーにのみ表示できるようにするメカニズムがあります。また、オブジェクト指向言語では、クラスまたはシングルトン オブジェクトがこの目的を果たすことを許可していることがよくあります (これが主な目的であるメカニズムがあるかどうかに関係なく)。さらに、言語はこれらのアプローチを融合することがよくあります。たとえば、Perlのパッケージは C++ の名前空間とほぼ同じですが、オプションでオブジェクト指向プログラミングのクラスとしても機能します。また、Java では変数と関数がクラスに編成されますが、それらのクラスが Ada のようなパッケージに編成されます。

代表的な言語のスコープ規則は次のとおりです。

C では、スコープは伝統的にリンケージまたは可視性と呼ばれ、特に変数についてはそうです。C は、グローバル スコープ (外部リンケージと呼ばれる)、モジュール スコープまたはファイル スコープの一種 (内部リンケージと呼ばれる)、およびローカル スコープ (関数内) を持つ、レキシカル スコープ言語です。関数内では、ブロック スコープを介してスコープをさらにネストできます。ただし、標準の C ではネストされた関数はサポートされていません。

変数の有効期間と可視性は、そのストレージ クラスによって決まります。C には、静的 (プログラム実行)、自動 (ブロック実行、スタックに割り当て)、手動 (ヒープに割り当て) の 3 種類の有効期間があります。変数では静的と自動のみがサポートされ、コンパイラによって処理されますが、手動で割り当てられたメモリは、異なる変数間で手動で追跡する必要があります。C には、外部リンケージ (グローバル)、内部リンケージ (おおよそファイル)、ブロック スコープ (関数を含む) の 3 つの可視性レベルがあります。ブロック スコープはネストすることができ、インクルードを使用することで異なるレベルの内部リンケージが可能です。C での内部リンケージは、翻訳単位レベル、つまりC プリプロセッサによって処理された後のソース ファイルでの可視性であり、特に関連するすべてのインクルードが含まれます。

C プログラムは個別のオブジェクト ファイルとしてコンパイルされ、リンカーを介して実行可能ファイルまたはライブラリにリンクされます。したがって、名前解決は、翻訳単位 (より緩く言えば「コンパイル単位」ですが、これは厳密には別の概念です) 内で名前を解決するコンパイラと、翻訳単位間で名前を解決するリンカーに分割されます。詳細については、 リンケージを参照してください。

C では、ブロック スコープを持つ変数は、宣言されたとき (ブロックの先頭ではない) にコンテキストに入り、ブロック内で (ネストされていない) 関数が呼び出されるとコンテキストから外れ、関数が返されるとコンテキストに戻り、ブロックの終了時にコンテキストから外れます。自動ローカル変数の場合、変数は宣言時に割り当てられ、ブロックの終了時に割り当て解除されますが、静的ローカル変数の場合は、プログラムの初期化時に割り当てられ、プログラムの終了時に割り当て解除されます。

次のプログラムは、ブロック スコープを持つ変数がブロックの途中でコンテキストに入り、ブロックの終了時にコンテキストを終了 (実際には割り当て解除) することを示しています。

#include <stdio.h> 

int main ( void ) { char x = 'm' ; printf ( "%c \n " , x ); { printf ( "%c \n " , x ); char x = 'b' ; printf ( "%c \n " , x ); } printf ( "%c \n " , x ); }  
     
   
  
     
       
     
  
   

プログラムは以下を出力します:

メートル
メートル
b
メートル

Cには他のレベルのスコープがあります。^[19]関数プロトタイプで使用される変数名は関数プロトタイプの可視性を持ち、関数プロトタイプの終了時にコンテキストを終了します。名前は使用されないため、コンパイルには役立ちませんが、ドキュメントには役立つ場合があります。GOTO文のラベル名には関数スコープがあります。

プログラムで使用するすべての変数は、前のコードで関数 main 本体の先頭で a、b、および result が int 型であると宣言したように、コードの前の時点でその型指定子を使用して宣言されている必要があります。変数は、グローバル スコープまたはローカル スコープのいずれかになります。グローバル変数は、すべての関数の外側にあるソース コードの本体で宣言された変数であり、ローカル変数は関数またはブロックの本体内で宣言された変数です。

最新バージョンでは、ネストされた語彙スコープ が許可されます。

Swift にはC++ と同様のスコープのルールがありますが、アクセス修飾子が異なります。

Goはブロックを使用して語彙的にスコープ化されています。^[3]

Java は語彙スコープです。

Javaクラスにはいくつかの種類の変数があります: ^[20]

ローカル変数

メソッド内または特定のブロック内で定義されます。これらの変数は、定義された場所とそれより低いレベルに対してローカルです。たとえば、メソッド内のループは、そのメソッドのローカル変数を使用できますが、その逆は使用できません。ループの変数 (そのループに対してローカル) は、ループが終了するとすぐに破棄されます。

メンバー変数

フィールドとも呼ばれる変数は、クラス内、メソッド外で宣言されます。デフォルトでは、これらの変数はそのクラス内のすべてのメソッドとパッケージ内のすべてのクラスで使用できます。

パラメータ

メソッド宣言内の変数です。

一般的に、括弧のセットは特定のスコープを定義しますが、クラス内のトップレベルの変数は、定義で使用される修飾子キーワードに応じて動作が異なる場合があります。次の表は、各修飾子によって許可されるメンバーへのアクセスを示しています。^[21]

JavaScriptには単純なスコープルールがありますが^[22]、変数の初期化と名前解決のルールは問題を引き起こす可能性があり、コールバックのクロージャの広範な使用は、関数が定義されたときの語彙コンテキスト（名前解決に使用されます）が、呼び出されたときの語彙コンテキスト（名前解決とは無関係）と大きく異なる可能性があることを意味します。JavaScriptオブジェクトにはプロパティの名前解決がありますが、これは別のトピックです。

JavaScriptには関数レベルでネストされたレキシカルスコープ^{[23]があり、グローバルコンテキストが最も外側のコンテキストになります。このスコープは変数と関数（}関数型の変数ではなく、関数宣言を意味します）の両方に使用されます。^[24]letおよびキーワードを使用したブロックスコープは、 ECMAScriptconst 6以降標準です。ブロックスコープは、ブロック全体を関数でラップしてから実行することで生成できます。これは、即時呼び出し関数式（IIFE）パターンとして知られています。

JavaScript のスコープは単純 (レキシカル、関数レベル) ですが、関連する初期化と名前解決のルールが混乱の原因となります。まず、スコープ外の名前への割り当ては、デフォルトでローカル変数ではなく新しいグローバル変数を作成します。次に、新しいローカル変数を作成するには、varキーワードを使用する必要があります。その後、関数の先頭に value を持つ変数が作成され、undefined割り当て式に到達したときに変数に値が割り当てられます。

Initialiserを持つ変数には、変数が作成された時ではなく、 VariableStatementが実行されたときにAssignmentExpressionの値が割り当てられます。^[25]

これは変数巻き上げ^[26]として知られており、宣言は関数の先頭に巻き上げられますが、初期化は巻き上げられません。第三に、初期化前に変数にアクセスするとundefined、構文エラーではなく、 が生成されます。第四に、関数の宣言では、変数の初期化とは異なり、宣言と初期化の両方が関数の先頭に巻き上げられます。たとえば、次のコードは、出力未定義ローカル変数の宣言はホイストされ、グローバル変数がシャドウされますが、初期化はホイストされないため、使用時に変数は未定義になります。

a = 1 ;関数f () { alert ( a ); var a = 2 ; } f ();  
  
  
     

さらに、関数は JavaScript のファーストクラス オブジェクトであり、コールバックとして割り当てられるか、関数から返されることが多いため、関数が実行されるときの名前解決は、関数が呼び出される語彙コンテキストや実行コンテキストではなく、関数が最初に定義された場所 (定義の語彙コンテキスト) に依存します。JavaScript の特定の関数 (特にコールバックとして使用されるクロージャ) のネストされたスコープ (最もグローバルなものから最もローカルなものまで) は、オブジェクトのプロトタイプ チェーンに倣って、 スコープ チェーンと呼ばれることがあります。

JavaScriptでは、関数がファーストクラスオブジェクトであるため、ネストされた関数を使用してクロージャを作成できます。^[27]ネストされた関数を囲む関数から返すと、囲む関数のローカル変数が返された関数の（非ローカルな）語彙コンテキストとして含まれ、クロージャが生成されます。例：

function newCounter () { // 呼び出し時に増加し (0 から開始) 、新しい値を返すカウンターを返しますvar a = 0 ; var b = function () { a ++ ; return a ; }; return b ; } c = newCounter (); alert ( c () + ' ' + c ()); // "1 2" を出力します  
  
  
     
          
   

  
      

クロージャは、コールバックに使用されるため、JavaScript で頻繁に使用されます。実際、関数をローカル コンテキストでコールバックとしてフックしたり、関数から関数を返したりすると、関数本体にバインドされていない変数がある場合にクロージャが作成されます (クロージャのコンテキストは、現在の語彙コンテキストのネストされたスコープ、つまり「スコープ チェーン」に基づいています)。これは偶発的な場合があります。パラメータに基づいてコールバックを作成する場合、パラメータはクロージャに格納する必要があります。そうしないと、変更される可能性のある囲みコンテキストの変数を参照するクロージャが誤って作成されます。^[28]

JavaScript オブジェクトのプロパティの名前解決は、プロトタイプ ツリー内の継承に基づいています (ツリー内のルートへのパスはプロトタイプ チェーンと呼ばれます)。これは、変数や関数の名前解決とは別のものです。

Lisp方言にはスコープに関するさまざまなルールがあります。

オリジナルの Lisp は動的スコープを使用していましたが、静的 (レキシカル) スコープを Lisp ファミリーに導入したのは、 ALGOLに触発されたSchemeでした。

Maclisp は、インタープリタではデフォルトで動的スコープを使用し、コンパイルされたコードではデフォルトでレキシカルスコープを使用していましたが、コンパイルされたコードはSPECIAL特定の変数の宣言を使用することで動的バインディングにアクセスできました。^[29]しかし、Maclisp はレキシカルバインディングを現代の言語で期待されるよりも最適化として扱い、現代の Lisp でレキシカルスコープに期待されるクロージャ機能は備えていませんでした。別の操作 は*FUNCTION、その問題の一部をいくぶん不器用に回避するために使用できました。^[30]

Common LispはScheme ^[31]からレキシカルスコープを採用し、Clojureも同様である。

ISLISPは通常の変数に対してはレキシカルスコープを持っています。動的変数もありますが、それらはすべてのケースで明示的にマークされています。それらはdefdynamic特別なフォームで定義され、特別なフォームでバインドされdynamic-let、明示的なdynamic特別なフォームでアクセスされる必要があります。^[32]

Emacs Lispのような他のLisp方言では、依然としてデフォルトで動的スコープが使用されています。Emacs Lispでは、バッファごとにレキシカルスコープが利用できるようになりました。^[33]

変数に関して、Python には関数スコープ、モジュール スコープ、およびグローバル スコープがあります。名前はスコープ (関数、モジュール、またはグローバル スコープ) の開始時にコンテキストに入り、ネストされていない関数が呼び出されるかスコープが終了するとコンテキストを終了します。変数の初期化前に名前が使用されると、実行時例外が発生します。変数が単にアクセスされる (代入されない) 場合、名前解決は LEGB (ローカル、囲む、グローバル、組み込み) ルールに従い、名前を最も狭い関連コンテキストに解決します。ただし、変数が代入される場合は、代入時ではなくレベル (関数、モジュール、またはグローバル) の開始時にスコープが始まる変数を宣言するのがデフォルトです。これらのルールは両方とも、使用前にglobalor nonlocal(Python 3 の場合) 宣言で上書きできます。これにより、マスクされた非ローカル変数がある場合でもグローバル変数にアクセスでき、グローバル変数または非ローカル変数に代入できます。

簡単な例として、関数は変数をグローバル スコープに解決します。

>>> def  f (): 
...     print ( x ) 
... 
>>> x  =  "global" 
>>> f () 
global

xは が呼び出される前に定義されるfため、 の定義内で が参照された後に定義されたとしても、エラーは発生しないことに注意してくださいf。 語彙的には、これは前方参照であり、Python で許可されています。

ここでの代入により新しいローカル変数が作成されますが、グローバル変数の値は変更されません。

>>> def  f (): 
...     x  =  "f" 
...     print ( x ) 
... 
>>> x  =  "global" 
>>> print ( x ) 
global 
>>> f () 
f 
>>> print ( x ) 
global

関数内で変数を割り当てると、その変数は関数に対してローカルとして宣言されます。したがって、その変数のスコープは関数全体となり、この割り当ての前に使用するとエラーが発生します。これは、ローカル変数のスコープが宣言から始まる C とは異なります。次のコードはエラーを発生させます。

>>> def  f (): 
...     print ( x ) 
...     x  =  "f" 
... 
>>> x  =  "global" 
>>> f ()
トレースバック (最後の呼び出しが最後):
  ファイル"<stdin>"、行1、<module>
  ファイル"<stdin>"、行2、f 
UnboundLocalError :ローカル変数 'x' が代入前に参照されています

デフォルトの名前解決ルールは、globalまたはnonlocal(Python 3 の場合) キーワードを使用して上書きできます。以下のコードでは、 でのglobal x宣言は、がグローバル変数に解決されることgを意味します。したがって、(すでに定義されているため) にアクセスでき、割り当ては新しいローカル変数を宣言するのではなく、グローバル変数に割り当てられます。 では宣言は不要であることに注意してください。変数に割り当てられないため、デフォルトでグローバル変数に解決されます。 xglobalf

>>> def  f (): 
...     print ( x ) 
... 
>>> def  g (): 
...     global  x 
...     print ( x ) 
...     x  =  "g" 
... 
>>> x  =  "global" 
>>> f ()
グローバル
>>> g ()
グローバル
>>> f () 
g

globalネストされた関数にも使用できます。ネストされていない関数と同様にグローバル変数への割り当てを許可するだけでなく、非ローカル変数が存在する場合にグローバル変数にアクセスするためにも使用できます。

>>> def  f (): 
...     def  g (): 
...        グローバル x 
...         print ( x ) 
...     x  =  "f" 
...     g () 
... 
>>> x  =  "global" 
>>> f ()
グローバル

ネストされた関数の場合、ネストされていない関数で nonlocal使用する場合と同様に、非ローカル変数に割り当てるための宣言もあります。global

>>> def  f (): 
...     def  g (): 
...         nonlocal  x   # Python 3 のみ
...         x  =  "g" 
...     x  =  "f" 
...     g () 
...     print ( x ) 
... 
>>> x  =  "global" 
>>> f () 
g 
>>> print ( x ) 
global

Rは、自由変数の値がグローバル変数の集合によって決定されるSの他の実装とは異なり、レキシカルスコープ言語です。一方、Rでは、自由変数の値は関数が作成されたコンテキストによって決定されます。 ^[34]スコープコンテキストには、プログラマが望む場合は動的スコープのエクスペリエンスをシミュレートできるさまざまな機能（などparent.frame()）を使用してアクセスできます。

ブロックスコープはありません:

a <- 1 { a <- 2 }メッセージ( a ) ## 2  

    

関数は、作成されたスコープにアクセスできます。

a <- 1 f <-関数() {メッセージ( a ) } f () ## 1  
   
  

関数内で作成または変更された変数はそこに残ります。

a <- 1 f <-関数() {メッセージ( a ) a <- 2メッセージ( a ) } f () ## 1 ## 2メッセージ( a ) ## 1  
   
  
    
  

関数内で作成または変更された変数は、囲むスコープへの割り当てが明示的に要求されない限り、そこに留まります。

a <- 1 f <-関数() {メッセージ( a ) a <<- 2メッセージ( a ) } f () ## 1 ## 2メッセージ( a ) ## 2  
   
  
    
  

R はデフォルトでレキシカルスコープを持ちますが、関数スコープは変更できます。

a <- 1 f <- function () { message ( a ) } my_env <- new.env () my_env $ a <- 2 f () ## 1 environment ( f ) <- my_env f () ## 2