<div id="readability-page-1" class="page"><div><hr>
<blockquote>
원글 : Marja Hölttä, <a href="https://v8.dev/blog/understanding-ecmascript-part-4">Understanding the ECMAScript spec, part 4</a>
</blockquote>
<ul>
<li>ECMAScript 명세 이해, 1부 - <a href="https://v8.dev/blog/understanding-ecmascript-part-1">원글</a> / <a href="https://ui.toast.com/posts/ko_20221116_1">번역글</a></li>
<li>ECMAScript 명세 이해, 2부 - <a href="https://v8.dev/blog/understanding-ecmascript-part-2">원글</a> / <a href="https://ui.toast.com/posts/ko_20221116_2">번역글</a></li>
<li>ECMAScript 명세 이해, 3부 - <a href="https://v8.dev/blog/understanding-ecmascript-part-3">원글</a> / <a href="https://ui.toast.com/posts/ko_20221116_3">번역글</a></li>
</ul>
<h2 id="한편-웹의-다른-부분에서는"><a href="#%ED%95%9C%ED%8E%B8-%EC%9B%B9%EC%9D%98-%EB%8B%A4%EB%A5%B8-%EB%B6%80%EB%B6%84%EC%97%90%EC%84%9C%EB%8A%94" aria-label="한편 웹의 다른 부분에서는 permalink"></a>한편, 웹의 다른 부분에서는</h2>
Mozilla의 <a href="https://github.com/jorendorff">Jason Orendorff</a>는 <a href="https://github.com/mozilla-spidermonkey/jsparagus/blob/master/js-quirks.md#readme">JS 구문상의 단점에 대한 심층 분석</a>을 발표했다. 구현 세부 사항은 다르지만 모든 JavaScript 엔진은 이러한 단점으로 인해 동일한 문제에 직면한다.
<h2 id="커버-문법cover-grammars"><a href="#%EC%BB%A4%EB%B2%84-%EB%AC%B8%EB%B2%95cover-grammars" aria-label="커버 문법cover grammars permalink"></a>커버 문법(Cover grammars)</h2>
이 글에서는 커버 문법에 대해 더 자세히 살펴본다. 먼저 모호해 보이는 구문 구조에 대한 문법을 명시하는 방법에 대해 살펴보자.
다시 말하면, <code>[In, Yield, Await]</code>의 첨자는 이 글에서 중요하지 않으므로 생략한다. 그 의미와 사용법에 대한 설명은 <a href="https://v8.dev/blog/understanding-ecmascript-part-3">3부</a>를 참조하자.
<h2 id="한정된-예측"><a href="#%ED%95%9C%EC%A0%95%EB%90%9C-%EC%98%88%EC%B8%A1" aria-label="한정된 예측 permalink"></a>한정된 예측</h2>
일반적으로 파서는 한정된 예측(일정량의 다음 토큰)을 기반으로 사용할 프로덕션을 결정한다.
어떤 경우에는 다음 토큰이 명확하게 사용할 프로덕션을 결정한다. 
<a href="https://tc39.es/ecma262/#prod-UpdateExpression">예를 들면</a>
<div data-language="text"><pre><code>UpdateExpression :
 LeftHandSideExpression
 LeftHandSideExpression ++
 LeftHandSideExpression --
 ++ UnaryExpression
 -- UnaryExpression</code></pre></div>
<code>UpdateExpression</code>을 구문 분석하고 다음 토큰이 <code>++</code> 또는 <code>--</code>이면 즉시 사용할 프로덕션을 알 수 있다. 다음 토큰이 둘 다 아니어도 현재 위치에서 <code>LeftHandSideExpression</code>을 구문 분석하고 구문 분석 후 무엇을 해야 할지 결정할 수 있다.
<code>LeftHandSideExpression</code> 다음에 오는 토큰이 <code>++</code>인 경우 사용할 프로덕션은 <code>UpdateExpression : LeftHandSideExpression ++</code>이다. <code>--</code>의 경우도 비슷하다. 그리고 <code>LeftHandSideExpression</code> 다음에 오는 토큰이 <code>++</code>와 <code>--</code>도 아닌 경우 프로덕션 <code>UpdateExpression: LeftHandSideExpression</code>을 사용한다.
<h3 id="화살표-함수-매개-변수-목록-또는-괄호로-묶인-표현식"><a href="#%ED%99%94%EC%82%B4%ED%91%9C-%ED%95%A8%EC%88%98-%EB%A7%A4%EA%B0%9C-%EB%B3%80%EC%88%98-%EB%AA%A9%EB%A1%9D-%EB%98%90%EB%8A%94-%EA%B4%84%ED%98%B8%EB%A1%9C-%EB%AC%B6%EC%9D%B8-%ED%91%9C%ED%98%84%EC%8B%9D" aria-label="화살표 함수 매개 변수 목록 또는 괄호로 묶인 표현식 permalink"></a>화살표 함수 매개 변수 목록 또는 괄호로 묶인 표현식?</h3>
화살표 함수 매개 변수 목록을 괄호로 묶인 표현식과 구별하는 것은 더 복잡하다.
예를 들면

위 예제가 화살표 함수의 시작일까?
<div data-language="js"><pre><code>let x = (a, b) =&gt; { return a + b };</code></pre></div>
아니면 위 예제처럼 괄호로 묶인 표현일까?

괄호로 묶인 것은 임의로 길 수 있기 때문에 우리는 한정된 양의 토큰을 기반으로 그것이 무엇인지 알 수 없다. 
다음과 같은 간단한 프로덕션이 있다고 가정해보자.
<div data-language="text"><pre><code>AssignmentExpression :
 ...
 ArrowFunction
 ParenthesizedExpression

ArrowFunction :
 ArrowParameterList =&gt; ConciseBody</code></pre></div>
이제 우리는 한정된 예측으로 사용할 프로덕션을 선택할 수 없다. <code>AssignmentExpression</code>을 구문 분석해야 하고 다음 토큰이 <code>(</code>인 경우 다음으로 구문 분석할 것을 어떻게 결정할까? <code>ArrowParameterList</code> 또는 <code>ParenthesizedExpression</code>을 구문 분석할 수 있지만 추측이 잘못될 수 있다.
<h3 id="매우-관대한-새로운-기호-cpeaapl"><a href="#%EB%A7%A4%EC%9A%B0-%EA%B4%80%EB%8C%80%ED%95%9C-%EC%83%88%EB%A1%9C%EC%9A%B4-%EA%B8%B0%ED%98%B8-cpeaapl" aria-label="매우 관대한 새로운 기호 cpeaapl permalink"></a>매우 관대한 새로운 기호 <code>CPEAAPL</code></h3>
명세는 <code>CoverParenthesizedExpressionAndArrowParameterList</code>(줄여서 <code>CPEAAPL</code>) 기호를 도입하여 이 문제를 해결한다. <code>CPEAAPL</code>은 실제로 <code>ParenthesizedExpression</code> 또는 <code>ArrowParameterList</code> 뒤에서 사용되는 기호이지만, 우리는 아직 어느 쪽인지 모른다.
<code>CPEAAPL</code>에 대한 <a href="https://tc39.es/ecma262/#prod-CoverParenthesizedExpressionAndArrowParameterList">프로덕션</a>은 매우 관대하여 <code>ParenthesizedExpressions</code> 및 <code>ArrowParameterLists</code>에서 발생할 수 있는 모든 구성을 허용한다.
<div data-language="text"><pre><code>CPEAAPL :
 ( Expression )
 ( Expression , )
 ( )
 ( ... BindingIdentifier )
 ( ... BindingPattern )
 ( Expression , ... BindingIdentifier )
 ( Expression , ... BindingPattern )</code></pre></div>
예를 들어, 다음 표현식은 유효한 <code>CPEAAPL</code>이다.
<div data-language="js"><pre><code>// 유효한 ParenthesizedExpression 과 ArrowParameterList
(a, b)
(a, b = 1)

// 유효한 ParenthesizedExpression
(1, 2, 3)
(function foo() { })

// 유효한 ArrowParameterList
()
(a, b,)
(a, ...b)
(a = 1, ...b)

// 둘 다 유효하진 않지만 여전히 CPEAAPL 이다.
(1, ...b)
(1, )</code></pre></div>
후행 쉼표와 <code>...</code>은 <code>ArrowParameterList</code>에서만 발생할 수 있다. <code>b = 1</code>과 같은 일부 구성은 둘 다에서 발생할 수 있지만 의미는 다르다.
<code>ParenthesizedExpression</code> 내부에서는 할당이고 <code>ArrowParameterList</code> 내부에서는 기본값이 있는 매개변수이다. 유효한 매개변수 이름(또는 매개변수 구조화 패턴)이 아닌 숫자 및 기타 <code>PrimaryExpressions</code>는 <code>ParenthesizedExpression</code>에서만 발생할 수 있다. 그러나 모두 <code>CPEAAPL</code> 내에서 발생할 수 있다.
<h3 id="프로덕션에서-cpeaapl-사용"><a href="#%ED%94%84%EB%A1%9C%EB%8D%95%EC%85%98%EC%97%90%EC%84%9C-cpeaapl-%EC%82%AC%EC%9A%A9" aria-label="프로덕션에서 cpeaapl 사용 permalink"></a>프로덕션에서 <code>CPEAAPL</code> 사용</h3>
이제 <a href="https://tc39.es/ecma262/#prod-AssignmentExpression"><code>AssignmentExpression</code> 프로덕션</a>에서 매우 관대한 <code>CPEAAPL</code>를 사용할 수 있다. (참고: <code>ConditionalExpression</code>은 여기에 표시되지 않은 긴 프로덕션 체인을 통해 <code>PrimaryExpression</code>으로 이어진다.)
<div data-language="text"><pre><code>AssignmentExpression :
 ConditionalExpression
 ArrowFunction
 ...

ArrowFunction :
 ArrowParameters =&gt; ConciseBody

ArrowParameters :
 BindingIdentifier
 CPEAAPL

PrimaryExpression :
 ...
 CPEAAPL</code></pre></div>
다시 <code>AssignmentExpression</code>을 구문 분석해야 하고 다음 토큰이 <code>(</code>인 상황이라고 가정해보자. 이제 우리는 <code>CPEAAPL</code>을 구문 분석하고 나중에 어떤 프로덕션을 사용할지 알 수 있다. <code>ArrowFunction</code> 또는 <code>ConditionalExpression</code>을 구문 분석하는지 여부는 중요하지 않다. 구문 분석할 다음 기호는 어떤 경우에도 <code>CPEAAPL</code>이다!
<code>CPEAAPL</code>을 구문 분석한 후 원래 <code>AssignmentExpression</code>(<code>CPEAAPL</code>을 포함하는 것)에 사용할 프로덕션을 결정할 수 있다. 이 결정은 <code>CPEAAPL</code> 다음 토큰을 기반으로 한다.
토큰이 <code>=&gt;</code>이면 다음 프로덕션을 사용한다.
<div data-language="text"><pre><code>AssignmentExpression :
 ArrowFunction</code></pre></div>
토큰이 다른 것이라면 다음 프로덕션을 사용한다.
<div data-language="text"><pre><code>AssignmentExpression :
 ConditionalExpression</code></pre></div>
예를 들어:
<div data-language="js"><pre><code>let x = (a, b) =&gt; { return a + b; };
// ^^^^^^
// CPEAAPL
// ^^
// CPEAAPL 다음 토큰

let x = (a, 3);
// ^^^^^^
// CPEAAPL
// ^
// CPEAAPL 다음 토큰</code></pre></div>
그 시점에서 우리는 <code>CPEAAPL</code>을 그대로 유지하고 프로그램의 나머지 부분을 계속 분석할 수 있다. 예를 들어, <code>CPEAAPL</code>이 <code>ArrowFunction</code> 내부에 있는 경우 나중에 수행할 수 있는 유효한 화살표 함수 매개변수 목록인지 여부를 아직 확인할 필요가 없다. (실제 파서는 유효성 검사를 즉시 수행하도록 선택할 수 있지만 명세 관점에서 볼 때 필요하지 않다.)
<h3 id="cpeaapl-제한"><a href="#cpeaapl-%EC%A0%9C%ED%95%9C" aria-label="cpeaapl 제한 permalink"></a><code>CPEAAPL</code> 제한</h3>
앞에서 보았듯이 <code>CPEAAPL</code>에 대한 문법적 프로덕션은 매우 관대하며 결코 유효하지 않은 구성(예: (1, ...a))을 허용한다. 문법에 따라 프로그램 구문 분석을 완료한 후 해당하는 불법 구성을 허용하지 않아야 한다.
명세에서는 다음과 같은 제한 사항을 추가하여 이 작업를 수행한다.
<blockquote>
<a href="https://tc39.es/ecma262/#sec-grouping-operator-static-semantics-early-errors">Static Semantics: Early Errors</a>
<code>PrimaryExpression : CPEAAPL</code>
<code>CPEAAPL</code>가 <code>ParenthesizedExpression</code>을 포함하지 않는 경우 구문 오류이다.
</blockquote>
<blockquote>
<a href="https://tc39.es/ecma262/#sec-primary-expression">Supplemental Syntax</a>
프로덕션의 인스턴스를 처리할 때
<code>PrimaryExpression : CPEAAPL</code>
다음 문법을 사용하여 <code>CPEAAPL</code>의 해석을 구체화 한다.
<code>ParenthesizedExpression : ( Expression )</code>
</blockquote>
이 말은 구문 트리에서 <code>PrimaryExpression</code> 대신 <code>CPEAAPL</code>이 발생하면 실제로는 <code>ParenthesizedExpression</code>이고 이것이 유일하게 유효한 프로덕션이다.
표현식은 비워둘 수 없으므로 <code>( )</code>은 유효한 <code>ParenthesizedExpression</code>이 아니다. <code>(1, 2, 3)</code>과 같은 쉼표로 구분된 목록은 쉼표 연산자에 의해 생성된다.
<div data-language="text"><pre><code>Expression :
 AssignmentExpression
 Expression , AssignmentExpression</code></pre></div>
마찬가지로 <code>ArrowParameters</code> 대신 <code>CPEAAPL</code>이 발생하면 다음과 같은 제한 사항이 적용된다.
<blockquote>
<a href="https://tc39.es/ecma262/#sec-arrow-function-definitions-static-semantics-early-errors">Static Semantics: Early Errors</a>
<code>ArrowParameters : CPEAAPL</code>
<code>CPEAAPL</code>가 <code>ArrowFormalParameters</code>을 포함하지 않는 경우 구문 오류이다.
</blockquote>
<blockquote>
<a href="https://tc39.es/ecma262/#sec-arrow-function-definitions">Supplemental Syntax</a>
프로덕션
<code>ArrowParameters</code>:<code>CPEAAPL</code>
가 인식되면 다음 문법을 사용하여 <code>CPEAAPL</code>의 해석을 구체화 한다.
<code>ArrowFormalParameters :( UniqueFormalParameters )</code>
</blockquote>
<h3 id="기타-커버-문법"><a href="#%EA%B8%B0%ED%83%80-%EC%BB%A4%EB%B2%84-%EB%AC%B8%EB%B2%95" aria-label="기타 커버 문법 permalink"></a>기타 커버 문법</h3>
<code>CPEAAPL</code> 외에도 명세는 모호해 보이는 다른 구성에 대해 커버 문법을 사용한다.
<code>ObjectLiteral</code>은 화살표 함수 매개변수 목록 내에서 발생하는 <code>ObjectAssignmentPattern</code>에 대한 커버 문법으로 사용한다. 즉, <code>ObjectLiteral</code>은 실제 객체 리터럴 내부에서 발생할 수 없는 구성을 허용한다는 것을 의미한다.
<div data-language="text"><pre><code>ObjectLiteral :
 ...
 { PropertyDefinitionList }

PropertyDefinition :
 ...
 CoverInitializedName

CoverInitializedName :
 IdentifierReference Initializer

Initializer :
 = AssignmentExpression</code></pre></div>
예를 들어
<div data-language="js"><pre><code>let o = { a = 1 }; // syntax error

// 기본값이 있는 구조화 매개변수가 있는 화살표 함수:
let f = ({ a = 1 }) =&gt; { return a; };
f({}); // returns 1
f({a : 6}); // returns 6</code></pre></div>
비동기 화살표 함수는 한정된 예측으로 모호해 보인다.

위 예제는 <code>async</code>라고 하는 함수에 대한 호출일까 아니면 비동기 화살표 함수에 대한 호출일까?
<div data-language="js"><pre><code>let x1 = async(a, b);
let x2 = async();
function async() { }

let x3 = async(a, b) =&gt; {};
let x4 = async();</code></pre></div>
이를 위해 문법은 <code>CPEAAPL</code>와 유사하게 작동하는 커버 문법 기호 <code>CoverCallExpressionAndAsyncArrowHead</code>를 정의한다.
<h2 id="요약"><a href="#%EC%9A%94%EC%95%BD" aria-label="요약 permalink"></a>요약</h2>
이 글에서 명세가 커버 문법을 어떻게 정의하고 한정된 예측을 기반으로 현재 구문 구조를 식별할 수 없는 경우에 어떻게 이를 사용하는지 살펴보았다.
특히, 화살표 함수 매개 변수 목록을 괄호로 묶은 표현식과 구별하고 명세가 커버 문법을 사용하여 모호하게 보이는 구조를 먼저 관대하게 구문 분석하고 나중에 정적 의미 규칙으로 제한하는 방법을 살펴보았다.</div></div>

Weekly Pick RSS Feed

이 글에서는 커버 문법에 대해 더 자세히 살펴본다. 먼저 모호해 보이는 구문 구조에 대한 문법을 명시하는 방법에 대해 살펴보자.

ECMAScript 명세 이해, 4부

댓글