5 표기 관례

)

은 nonterminal WhileStatement가 token while, 그 뒤의 left parenthesis token, 그 뒤의 Expression, 그 뒤의 right parenthesis token, 그 뒤의 Statement를 나타낸다고 명시합니다. Expression과 Statement의 occurrence는 그 자체로 nonterminal입니다. 또 다른 예로, syntactic definition:

은 ArgumentList가 하나의 AssignmentExpression을 나타내거나, ArgumentList 뒤에 comma가 오고 그 뒤에 AssignmentExpression이 오는 것을 나타낼 수 있다고 명시합니다. ArgumentList의 이 정의는 recursive합니다. 즉 자신을 기준으로 정의됩니다. 그 결과 ArgumentList는 comma로 구분된 임의의 양수 개수의 argument를 포함할 수 있으며, 각 argument expression은 AssignmentExpression입니다. 이러한 nonterminal의 recursive definition은 흔합니다.

5.1.5.3 Optional Symbols

terminal 또는 nonterminal 뒤에 나타날 수 있는 subscripted suffix “_opt”는 optional symbol을 나타냅니다. optional symbol을 포함하는 alternative는 실제로 optional element를 생략한 것과 포함한 것, 두 right-hand side를 명시합니다. 이는 다음을 의미합니다:

opt

은 다음에 대한 편리한 abbreviation입니다:

그리고 다음도:

for

(

opt

;

opt

)

다음에 대한 편리한 abbreviation입니다:

ForStatement

for

(

;

opt

)

for

(

;

opt

)

이는 다시 다음에 대한 abbreviation입니다:

ForStatement

for

(

;

)

for

(

;

)

for

(

;

)

for

(

;

)

따라서 이 예에서 nonterminal ForStatement는 실제로 네 개의 alternative right-hand side를 가집니다.

5.1.5.4 Grammatical Parameters

production은 정의되는 production의 nonterminal symbol에 suffix로 나타날 수 있는 “_[parameters]” 형식의 subscripted annotation으로 parameterized될 수 있습니다. “_parameters”는 하나의 name이거나 comma로 구분된 name의 list일 수 있습니다. parameterized production은 parameterized nonterminal symbol에 underscore를 앞에 붙인 parameter name의 모든 조합을 덧붙여 정의하는 production 집합에 대한 shorthand입니다. 이는 다음을 의미합니다:

[Return]

은 다음에 대한 편리한 abbreviation입니다:

그리고 다음도:

[Return, In]

다음에 대한 abbreviation입니다:

StatementList_Return_In

여러 parameter는 combinatoric number의 production을 생성하며, 그 모두가 완전한 grammar에서 반드시 참조되는 것은 아닙니다.

production의 right-hand side에 있는 nonterminal reference도 parameterized될 수 있습니다. 예를 들어:

[+In]

은 다음과 말하는 것과 equivalent합니다:

ExpressionStatement_In

그리고:

[~In]

은 다음과 equivalent합니다:

nonterminal reference는 parameter list와 “_opt” suffix를 모두 가질 수 있습니다. 예를 들어:

[+In]

opt

은 다음에 대한 abbreviation입니다:

Initializer_In

right-hand side nonterminal reference에서 parameter name 앞에 “_?”를 붙이면, 그 parameter value는 현재 production의 left-hand side symbol에 대한 reference에서 parameter name이 occurrence하는지에 따라 달라집니다. 예를 들어:

[In]

[?In]

은 다음에 대한 abbreviation입니다:

VariableDeclaration_In

Initializer_In

right-hand side alternative 앞에 “[+parameter]”가 붙으면, 그 alternative는 production의 nonterminal symbol을 참조할 때 named parameter가 사용된 경우에만 available합니다. right-hand side alternative 앞에 “[~parameter]”가 붙으면, 그 alternative는 production의 nonterminal symbol을 참조할 때 named parameter가 사용되지 않은 경우에만 available합니다. 이는 다음을 의미합니다:

[Return]

[+Return]

은 다음에 대한 abbreviation입니다:

그리고 다음도:

[Return]

[~Return]

다음에 대한 abbreviation입니다:

5.1.5.5 one of

grammar definition에서 colon(s) 뒤에 “one of”라는 단어가 오면, 이는 다음 line 또는 lines의 각 terminal symbol이 alternative definition임을 의미합니다. 예를 들어 ECMAScript의 lexical grammar에는 다음 production이 포함됩니다:

NonZeroDigit

one of

이는 단지 다음에 대한 편리한 abbreviation입니다:

NonZeroDigit

5.1.5.6 [empty]

production의 right-hand side에 “[empty]”라는 phrase가 나타나면, 이는 그 production의 right-hand side가 terminal이나 nonterminal을 포함하지 않음을 나타냅니다.

5.1.5.7 Lookahead Restrictions

production의 right-hand side에 “[lookahead = seq]”라는 phrase가 나타나면, 이는 immediately following input token sequence의 prefix가 token sequence seq인 경우에만 그 production을 사용할 수 있음을 나타냅니다. 마찬가지로 “[lookahead ∈ set]”에서 set이 token sequence의 finite non-empty set이면, immediately following token sequence의 prefix가 set의 어떤 element인 경우에만 그 production을 사용할 수 있음을 나타냅니다. 편의를 위해 set은 nonterminal로도 쓸 수 있으며, 이 경우 그 nonterminal이 expand될 수 있는 모든 token sequence의 집합을 나타냅니다. nonterminal이 무한히 많은 distinct token sequence로 expand될 수 있으면 이는 editorial error로 간주됩니다.

이러한 condition은 negated될 수 있습니다. “[lookahead ≠ seq]”는 containing production이 seq가 immediately following input token sequence의 prefix가 아닌 경우에만 사용될 수 있음을 나타내며, “[lookahead ∉ set]”는 immediately following token sequence의 prefix가 set의 어떤 element도 아닌 경우에만 production을 사용할 수 있음을 나타냅니다.

예를 들어 다음 정의가 주어졌을 때:

one of

다음 정의는:

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

DecimalDigits

DecimalDigit

[lookahead ∉ DecimalDigit]

letter n 뒤에 하나 이상의 decimal digit가 오며 그 첫 번째가 even인 경우, 또는 다른 decimal digit가 뒤따르지 않는 decimal digit 중 하나와 match합니다.

이 phrase들이 syntactic grammar에서 사용될 때는, 이후 token을 결정하려면 이후 위치에서 어떤 lexical goal symbol을 사용할지 알아야 하기 때문에 immediately following token sequence를 unambiguously identify할 수 없을 수도 있습니다. 따라서 syntactic grammar에서 이것들이 사용될 때, lexical goal symbol 선택이 resulting token sequence의 prefix가 seq인지 여부를 바꿀 수 있다면 token sequence seq가 lookahead restriction에(시퀀스 집합의 일부로 포함되는 경우도 포함) 나타나는 것은 editorial error로 간주됩니다.

5.1.5.8 [no LineTerminator here]

syntactic grammar의 production의 right-hand side에 “[no LineTerminator here]”라는 phrase가 나타나면, 이는 그 production이 restricted production임을 나타냅니다. 즉 indicated position의 input stream에 LineTerminator가 occurrence하면 사용할 수 없습니다. 예를 들어 production:

ThrowStatement

throw

[no LineTerminator here]

;

은 script에서 throw token과 Expression 사이에 LineTerminator가 occurrence하면 그 production을 사용할 수 없음을 나타냅니다.

LineTerminator의 존재가 restricted production에 의해 forbidden되지 않는 한, LineTerminator는 input element의 stream에서 연속된 두 token 사이에 임의의 횟수로 나타날 수 있으며 script의 syntactic acceptability에 영향을 주지 않습니다.

5.1.5.9 but not

production의 right-hand side는 “but not”이라는 phrase를 사용한 다음 excluded될 expansion을 표시하여 특정 expansion이 허용되지 않음을 명시할 수 있습니다. 예를 들어 production:

Identifier

IdentifierName

but not ReservedWord

은 nonterminal Identifier가 IdentifierName을 replace할 수 있는 어떤 code point sequence로도 replace될 수 있되, 같은 code point sequence가 ReservedWord를 replace할 수 없는 경우에 한한다는 의미입니다.

5.1.5.10 Descriptive Phrases

마지막으로, 모든 alternative를 나열하는 것이 비실용적인 경우에는 몇몇 nonterminal symbol이 sans-serif type의 descriptive phrase로 설명됩니다:

SourceCharacter

any Unicode code point

5.2 Algorithm Conventions

이 명세는 algorithm의 step을 명시하기 위해 numbered list를 자주 사용합니다. 이러한 algorithm은 ECMAScript language construct의 요구되는 semantics를 정밀하게 명시하는 데 사용됩니다. algorithm은 특정 implementation technique의 사용을 함의하도록 의도되지 않습니다. 실제로 주어진 feature를 구현하는 데 더 효율적인 algorithm이 있을 수 있습니다.

algorithm은 algorithm step 안에서 해당 위치에 전달된 argument를 참조하는 데 사용할 수 있는 alias name의 ordered, comma-separated sequence로 명시적으로 parameterized될 수 있습니다. optional parameter는 surrounding brackets([ , name ])로 표시되며 algorithm step 안에서는 required parameter와 다르지 않습니다. rest parameter는 parameter list의 끝에 나타날 수 있으며, leading ellipsis(, ...name)로 표시됩니다. rest parameter는 required 및 optional parameter 뒤에 제공된 모든 argument를 List로 capture합니다. 그러한 additional argument가 없으면 그 List는 empty입니다.

algorithm step은 sequential substep으로 세분될 수 있습니다. substep은 indented되며 그 자체가 다시 indented substep으로 더 나뉠 수 있습니다. outline numbering convention은 substep을 식별하는 데 사용되며, 첫 번째 수준의 substep은 lowercase alphabetic character로, 두 번째 수준의 substep은 lowercase roman numeral로 labelled됩니다. 세 수준보다 더 많은 수준이 필요하면 이 규칙이 반복되며 네 번째 수준은 numeric label을 사용합니다. 예를 들어:

Top-level step
1. Substep.
2. Substep.
  1. Subsubstep.
    1. Subsubsubstep
      1. Subsubsubsubstep
        Subsubsubsubsubstep

step 또는 substep은 그 substep을 condition하는 “if” predicate로 작성될 수 있습니다. 이 경우 substep은 predicate가 true일 때만 적용됩니다. step 또는 substep이 “else”라는 단어로 시작하면, 이는 같은 level의 preceding “if” predicate step의 negation인 predicate입니다.

step은 그 substep의 iterative application을 명시하기 위해 “For each” 또는 “Repeat”로 시작할 수 있습니다.

“Assert:”로 시작하는 step은 algorithm의 invariant condition을 assertion합니다. 이러한 assertion은 그렇지 않으면 암시적일 algorithmic invariant를 명시적으로 만들기 위해 사용됩니다. 마찬가지로 “NOTE:”로 시작하는 step은 nearby step에 관련된 context를 제공합니다. Assertion step과 note step은 strictly informative입니다. 이는 추가 semantic requirement를 더하지 않으므로 implementation이 check할 필요가 없습니다.

algorithm step은 “Let x be someValue” 형식을 사용하여 어떤 value에 대해서도 named alias를 선언할 수 있습니다. 이러한 alias는 x와 someValue 모두 같은 underlying data를 참조하고 어느 쪽에 대한 modification도 양쪽에 보인다는 점에서 reference-like입니다. 이 reference-like behaviour를 피하고자 하는 algorithm step은 right-hand side의 copy를 명시적으로 만들어야 합니다. “Let x be a copy of someValue”는 someValue의 shallow copy를 만듭니다.

일단 선언되면, alias는 이후의 어떤 step에서도 참조될 수 있으며 alias의 declaration 이전 step에서 참조되어서는 안 됩니다. alias는 “Set x to someOtherValue” 형식을 사용하여 수정될 수 있습니다.

5.2.1 Evaluation Order

complex expression이 algorithm step에 나타날 때, 이는 left-to-right, inside-to-outside order로 evaluated되는 것으로 이해해야 합니다. 예를 들어 step

Return A(B(), C.[[D]]) + E(F()).

은 다음과 equivalent합니다

Let tmp1 be B().
Let tmp2 be C.[[D]].
Let tmp3 be A(tmp1, tmp2).
Let tmp4 be F().
Let tmp5 be E(tmp4).
Let tmp6 be tmp3 + tmp5.
Return tmp6.

여기서 여러 tmpN alias는 ephemeral하며 이 step들 안에서만 visible합니다.

5.2.2 Abstract Operations

이 명세의 여러 부분에서 사용하기 쉽도록, abstract operations라고 하는 일부 algorithm은 이름을 가지며 parameterized functional form으로 작성되어 다른 algorithm 안에서 이름으로 참조될 수 있습니다. abstract operation은 보통 OperationName(arg1, arg2)와 같은 functional application style을 사용하여 참조됩니다. 일부 abstract operation은 class-like specification abstraction의 polymorphically dispatched method로 취급됩니다. 그러한 method-like abstract operation은 보통 someValue.OperationName(arg1, arg2)와 같은 method application style을 사용하여 참조됩니다.

5.2.3 Syntax-Directed Operations

syntax-directed operation은 named operation이며, 그 정의는 algorithm들로 구성되고, 각 algorithm은 ECMAScript grammar 중 하나의 하나 이상의 production과 associated됩니다. 여러 alternative definition을 가진 production은 보통 각 alternative마다 distinct algorithm을 가집니다. algorithm이 grammar production과 associated될 때, 이는 production alternative의 terminal 및 nonterminal symbol을 algorithm의 parameter인 것처럼 참조할 수 있습니다. 이런 방식으로 사용될 때 nonterminal symbol은 source text를 parsing할 때 match되는 실제 alternative definition을 참조합니다. grammar production 또는 그로부터 derived된 Parse Node가 matched by한 source text는 match에 참여한 첫 번째 terminal의 시작에서 시작하여 match에 참여한 마지막 terminal의 끝에서 끝나는 source text 부분입니다.

algorithm이 production alternative와 associated될 때, alternative는 보통 “[ ]” grammar annotation 없이 표시됩니다. 그러한 annotation은 alternative의 syntactic recognition에만 영향을 주어야 하며 alternative에 associated된 semantics에는 영향을 주지 않아야 합니다.

Syntax-directed operation은 다음 algorithm의 steps 1, 3, 그리고 4에 있는 convention을 사용하여 parse node와, 선택적으로, 다른 parameter와 함께 invoked됩니다:

Let status be SyntaxDirectedOperation of SomeNonTerminal.
Let someParseNode be the parse of some source text.
Perform SyntaxDirectedOperation of someParseNode.
Perform SyntaxDirectedOperation of someParseNode with argument "value".

명시적으로 달리 specified되지 않는 한, 모든 chain production은 그 production의 left-hand side nonterminal에 적용될 수 있는 모든 operation에 대해 implicit definition을 가집니다. implicit definition은 같은 operation을 같은 parameter가 있으면 그대로, chain production의 sole right-hand side nonterminal에 다시 적용하고 그 결과를 반환합니다. 예를 들어 어떤 algorithm에 “Return Evaluation of Block” 형식의 step이 있고 다음 production이 있다고 가정합니다:

Block

{

}

그러나 Evaluation operation이 그 production에 algorithm을 associate하지 않는 경우, Evaluation operation은 다음 형식의 association을 implicitly 포함합니다:

Runtime Semantics: Evaluation

Block

{