5 記法上の慣例

)

は、非終端WhileStatementが、token while、左括弧token、Expression、右括弧token、Statementの順で構成されることを述べています。ExpressionおよびStatementの出現は、それ自体が非終端です。別の例として、構文上の定義：

は、ArgumentListが単一のAssignmentExpressionを表す場合も、ArgumentListに続いてカンマ、その後にAssignmentExpressionが続くものを表す場合もあることを述べています。このArgumentListの定義は再帰的です。つまり、それ自身を用いて定義されています。その結果、ArgumentListは、カンマで区切られた任意の正の個数のargumentsを含むことができ、各argument expressionはAssignmentExpressionです。このような非終端の再帰的定義は一般的です。

5.1.5.3 任意記号

終端または非終端の後に現れることがある下付き接尾辞“_opt”は、任意記号を示します。任意記号を含む代替は、実際には、任意要素を省略するものとそれを含むものの2つの右辺を指定します。これは、次が：

opt

次の便利な省略形であることを意味します：

また、次が：

for

(

opt

;

opt

)

次の便利な省略形であることも意味します：

ForStatement

for

(

;

opt

)

for

(

;

opt

)

これはさらに次の省略形です：

ForStatement

for

(

;

)

for

(

;

)

for

(

;

)

for

(

;

)

したがって、この例では、非終端ForStatementは実際には4つの代替右辺を持ちます。

5.1.5.4 文法パラメーター

生成は、その生成によって定義される非終端記号の接尾辞として現れることがある、“_[parameters]”という形式の下付き注釈によってパラメーター化されても構いません。“_parameters”は、単一の名前またはカンマ区切りの名前のリストのいずれかです。パラメーター化された生成は、パラメーター名のすべての組み合わせを定義する生成の集合の省略形であり、各パラメーター名にはアンダースコアが前置され、パラメーター化された非終端記号に追加されます。これは、次が：

[Return]

次の便利な省略形であることを意味します：

また、次が：

[Return, In]

次の省略形であることも意味します：

StatementList_Return_In

複数のパラメーターは組み合わせ的な数の生成を生み出しますが、そのすべてが完全な文法内で必ずしも参照されるわけではありません。

生成の右辺上の非終端への参照もパラメーター化できます。たとえば：

[+In]

は、次のように言うことと等価です：

ExpressionStatement_In

また：

[~In]

は、次と等価です：

非終端参照は、パラメーターリストと“_opt”接尾辞の双方を持つことができます。たとえば：

[+In]

opt

は、次の省略形です：

Initializer_In

右辺の非終端参照でパラメーター名に“_?”を前置すると、そのパラメーター値は現在の生成の左辺記号への参照におけるそのパラメーター名の出現に依存します。たとえば：

[In]

[?In]

は、次の省略形です：

VariableDeclaration_In

Initializer_In

右辺の代替が“[+parameter]”で前置されている場合、その代替は、生成の非終端記号を参照する際にその名前付きパラメーターが使用された場合にのみ利用可能です。右辺の代替が“[~parameter]”で前置されている場合、その代替は、生成の非終端記号を参照する際にその名前付きパラメーターが使用されなかった場合にのみ利用可能です。これは、次が：

[Return]

[+Return]

次の省略形であることを意味します：

また、次が：

[Return]

[~Return]

次の省略形であることも意味します：

5.1.5.5 one of

文法定義内でコロンの後に“one of”という語が続く場合、それは後続の行または複数行上の終端記号の各々が代替定義であることを意味します。たとえば、ECMAScriptの字句文法には次の生成が含まれます：

NonZeroDigit

one of

これは単に次の便利な省略形です：

NonZeroDigit

5.1.5.6 [empty]

“[empty]”という句が生成の右辺として現れる場合、それはその生成の右辺が終端も非終端も含まないことを示します。

5.1.5.7 先読み制約

“[lookahead = seq]”という句が生成の右辺に現れる場合、それは直後に続く入力token列のprefixがtoken列seqである場合にのみ、その生成を使用できることを示します。同様に、“[lookahead ∈ set]”は、setがtoken列の有限の非空集合である場合、直後に続くtoken列のprefixがsetのいずれかの要素である場合にのみ、その生成を使用できることを示します。便宜上、その集合は非終端として書くこともでき、その場合、それはその非終端が展開され得るすべてのtoken列の集合を表します。その非終端が無限に多くの異なるtoken列へ展開され得る場合、それは編集上の誤りと見なされます。

これらの条件は否定できます。“[lookahead ≠ seq]”は、含まれる生成が、seqが直後に続く入力token列のprefixでない場合にのみ使用できることを示し、“[lookahead ∉ set]”は、setのいずれの要素も直後に続くtoken列のprefixでない場合にのみ、その生成を使用できることを示します。

例として、次の定義が与えられた場合：

one of

この定義：

[lookahead ∉ { 1, 3, 5, 7, 9 }]

DecimalDigits

DecimalDigit

[lookahead ∉ DecimalDigit]

は、文字nに続いて1個以上の10進数字があり、その最初のものが偶数であるもの、または、別の10進数字が後続しない10進数字のいずれかに一致します。

これらの句が構文文法で使用される場合、後続のtokensを決定するには後の位置でどの字句goal symbolを使用するかを知る必要があるため、直後に続くtoken列を曖昧さなく識別できない場合があることに注意してください。そのため、これらが構文文法で使用される場合、使用する字句goal symbolsの選択によってseqが結果のtoken列のprefixであるかどうかが変わり得るならば、token列seqが先読み制約内（列集合の一部としての場合を含む）に現れることは編集上の誤りと見なされます。

5.1.5.8 [no LineTerminator here]

“[no LineTerminator here]”という句が構文文法の生成の右辺に現れる場合、それはその生成が制限された生成であることを示します。すなわち、示された位置で入力ストリーム内にLineTerminatorが発生する場合、その生成を使用してはなりません。たとえば、生成：

ThrowStatement

throw

[no LineTerminator here]

;

は、script内でthrow tokenとExpressionの間にLineTerminatorが発生する場合、その生成を使用してはならないことを示します。

LineTerminatorの存在が制限された生成によって禁止されていない限り、入力要素のストリーム内で任意の2つの連続するtokensの間に任意の数のLineTerminatorが現れても、scriptの構文上の受理可能性には影響しません。

5.1.5.9 but not

生成の右辺は、“but not”という句を使用し、その後に除外される展開を示すことで、特定の展開が許可されないことを指定できます。たとえば、生成：

Identifier

IdentifierName

but not ReservedWord

は、非終端Identifierが、IdentifierNameを置き換え得る任意の符号位置列であって、同じ符号位置列がReservedWordを置き換え得ないものによって置き換えられることを意味します。

5.1.5.10 説明句

最後に、いくつかの非終端記号は、すべての代替を列挙することが非実用的である場合に、sans-serif体の説明句によって記述されます：

SourceCharacter

any Unicode code point

5.2 アルゴリズムの慣例

この仕様は、アルゴリズムのステップを指定するために番号付きリストをよく使用します。これらのアルゴリズムは、ECMAScript言語構造の要求される意味論を正確に指定するために使用されます。これらのアルゴリズムは、特定の実装技法の使用を暗示することを意図していません。実際には、与えられた機能を実装するために、より効率的なアルゴリズムが利用可能である場合があります。

アルゴリズムは、順序付きのカンマ区切りのalias名の列によって明示的にパラメーター化されても構いません。これらのalias名は、アルゴリズムステップ内でその位置に渡されたargumentを参照するために使用できます。任意パラメーターは、周囲の角括弧（[ , name ]）で示され、アルゴリズムステップ内では必須パラメーターと何ら異なりません。restパラメーターは、leading ellipsis（, ...name）で示され、パラメーターリストの末尾に現れても構いません。restパラメーターは、必須および任意パラメーターの後に提供されたすべてのargumentsをListへ取り込みます。そのような追加のargumentsがない場合、そのListは空です。

アルゴリズムステップは、順次的なサブステップへ細分化されても構いません。サブステップはインデントされ、それ自体もさらにインデントされたサブステップへ分割されても構いません。サブステップを識別するためにアウトライン番号付けの慣例が使用され、第一レベルのサブステップは小文字のアルファベット文字で、第二レベルのサブステップは小文字のローマ数字でラベル付けされます。3レベルを超える必要がある場合、これらの規則は繰り返され、第4レベルでは数値ラベルが使用されます。たとえば：

トップレベルステップ
1. サブステップ。
2. サブステップ。
  1. サブサブステップ。
    1. サブサブサブステップ
      1. サブサブサブサブステップ
        サブサブサブサブサブステップ

ステップまたはサブステップは、そのサブステップを条件付ける“if”述語として書かれることがあります。この場合、サブステップは述語がtrueである場合にのみ適用されます。ステップまたはサブステップが“else”という語で始まる場合、それは同じレベルの直前の“if”述語ステップの否定である述語です。

ステップは、そのサブステップの反復適用を指定するために“For each”または“Repeat”で始まることがあります。

“Assert:”で始まるステップは、そのアルゴリズムの不変条件を表明します。そのような表明は、そうでなければ暗黙であるアルゴリズム上の不変条件を明示するために使用されます。同様に、“NOTE:”で始まるステップは、近くのステップに関する関連する文脈を提供します。Assertion stepsおよびnote stepsは厳密に情報提供であり、追加の意味的要件を加えないため、実装によってチェックされる必要はありません。

アルゴリズムステップは、“Let x be someValue”という形式を使用して任意の値に名前付きaliasを宣言できます。これらのaliasは、xとsomeValueの双方が同じ基礎データを参照し、どちらに対する変更も双方から見えるという点で参照のようなものです。この参照のような振る舞いを避けたいアルゴリズムステップは、右辺のコピーを明示的に作成するべきです：“Let x be a copy of someValue”はsomeValueの浅いコピーを作成します。

一度宣言されると、aliasは後続の任意のステップで参照できますが、aliasの宣言より前のステップから参照してはなりません。aliasは、“Set x to someOtherValue”という形式を使用して変更できます。

5.2.1 評価順序

複雑な式がアルゴリズムステップ内に現れる場合、それらは左から右、内側から外側の順序で評価されるものと理解されます。たとえば、ステップ

A(B(), C.[[D]]) + E(F())を返す。

は次と等価です

tmp1 をB()とする。
tmp2 をC.[[D]]とする。
tmp3 をA(tmp1, tmp2)とする。
tmp4 をF()とする。
tmp5 をE(tmp4)とする。
tmp6 をtmp3 + tmp5とする。
tmp6 を返す。

ここで、さまざまなtmpN aliasesは一時的なものであり、これらのステップ内でのみ見えます。

5.2.2 抽象操作

この仕様の複数の部分での使用を容易にするため、abstract operationsと呼ばれる一部のアルゴリズムは、名前付きで、パラメーター化された関数形式で書かれ、他のアルゴリズム内から名前によって参照できるようにされています。抽象操作は通常、OperationName(arg1, arg2)のような関数適用スタイルを使用して参照されます。一部の抽象操作は、class風の仕様抽象化のpolymorphically dispatched methodsとして扱われます。そのようなmethod風の抽象操作は通常、someValue.OperationName(arg1, arg2)のようなメソッド適用スタイルを使用して参照されます。

5.2.3 Syntax-Directed Operations

syntax-directed operationとは、名前付き操作であり、その定義はアルゴリズムから構成され、それぞれがECMAScript文法のいずれかの1つ以上の生成に関連付けられます。複数の代替定義を持つ生成は通常、各代替について別個のアルゴリズムを持ちます。アルゴリズムが文法生成に関連付けられる場合、それはその生成代替の終端および非終端記号を、あたかもアルゴリズムのパラメーターであるかのように参照できます。この方法で使用される場合、非終端記号は、source textを解析する際に一致した実際の代替定義を指します。文法生成またはそれから導出されたParse Nodeによって一致されたsource textとは、その一致に参加した最初の終端の開始から始まり、その一致に参加した最後の終端の終了で終わるsource textの部分です。

アルゴリズムが生成代替に関連付けられる場合、その代替は通常、“[ ]”文法注釈なしで示されます。そのような注釈は、その代替の構文認識にのみ影響するべきであり、その代替に関連付けられた意味論には影響しません。

Syntax-directed operationsは、以下のアルゴリズム内のステップ1、3、および4上の慣例を使用して、parse nodeと、任意で他のパラメーターとともに呼び出されます：

status をSomeNonTerminalのSyntaxDirectedOperationとする。
someParseNode を何らかのsource textのparseとする。
someParseNode のSyntaxDirectedOperationを実行する。
argument "value" 付きでsomeParseNode のSyntaxDirectedOperationを実行する。

明示的に別途指定されない限り、すべてのchain productionsは、その生成の左辺非終端に適用され得るすべての操作について暗黙の定義を持ちます。暗黙の定義は、同じ操作を、同じパラメーターがあればそれらとともに、chain productionの唯一の右辺非終端へ再適用し、その後結果を返すだけです。たとえば、あるアルゴリズムに“Return Evaluation of Block”という形式のステップがあり、次の生成があると仮定します：

Block

{

}

しかしEvaluation操作がその生成とアルゴリズムを関連付けていない場合、そのときEvaluation操作は暗黙に次の形式の関連付けを含みます：

Runtime Semantics: Evaluation

Block

{