Twitter hashtag: #esspec
https://youtu.be/fwzJPnOa3cA
自己紹介
syumai
GoとTSやってます
Jun Yasumura Jun Yasumura.icon
趣味はCommon Lisp
HTMLの仕様書を読んだ経験あり→仕様書はそうなった経緯が書かれていないものだということを痛感。意図を理解するまで１年半かかった。
元バックエンド(Perl)→講師→休職→復帰。フロントエンド周りの技術を学び、世の中のHTML/CSSコーダーさんを幸せにすることが今の目標。
輪読会は英語の勉強にも役立っています！
noyannoyan.icon
Reactが大好きです。React内部のコードリーディングに時間を溶かしていました
最近goをはじめました。三日坊主です。
yebis0942yebis0942.icon
Reactたまにやってます
おーみーaumy.icon
高卒無職になりました
趣味でReact, Rust, Haskellなどをいじって遊んでいます
自作プログラミング言語を作ろうとしています
grammarのことをgrammerだと思っていた
tars0x9752 (たーず / naoki aoyama)
Matrix: @tars0x9752:matrix.org
仕事ではwebアプリ・モバイルアプリ開発のフロントエンド～バックエンドをTSで書いたりしてます。
普段英語を人前で話す機会とかは全然ないので、発音とかお聞き苦しいかもですが、ご容赦ください。（がんばります）
バットマンの映画が面白かった
今回の範囲
5.1.5 Grammar Notation の The subscripted suffix “opt”...
13〜16の文法規則に当てはまらないけど妥当なECMAScriptというのが存在する
構文文法では、曖昧性を除去するために一般化された生成規則を使う場合がある
例: オブジェクトリテラル, 分割代入
この「一般化された生成規則」が受理するトークン列は妥当なscriptやmoduleにならないこともある
受理可能なトークン列を制限するためにsupplemental grammarが用意されている
典型的にはearly error ruleによって"P must cover an N"といった制約をかける
P: 一般化された生成規則によってパースされたParse Node
N: supplemental grammarの非終端記号
yebis0942.iconパーサーの実装上の都合で、一旦緩い文法でパースしてから厳密な文法でパースするという二段階のプロセスを踏んでいるということかな
曖昧性 ambiguity とは
ECMAScriptのパース処理では、トークンを1つだけ先読み (lookahead) すればパース結果が確定するのが基本
2つ以上のトークンを先読みしないとパース結果が確定しない場合はパース結果が曖昧となる
$ DecimalDigit [\rm{lookahead} ∉ \it{DecimalDigit}]
DecimalDigitではない任意の要素が続く
トークンの先読み数を1つに制限するのは？
() => { () => { () => {} } }のように無限にネスト可能な文法要素では必要な先読み数も無限になりうるから？
アロー関数の文法定義を見てみる
CoverParenthesizedExpressionAndArrowParameterList
式を丸括弧でくくったもの or アロー関数のパラメータリスト
yebis0942.icon(a = 1, b = 1)みたいなやつにマッチするっぽい
Supplemental Syntax
$ PrimaryExpression _{\lbrack \rm{Yield, Await} \rbrack}: CoverParenthesizedExpressionAndArrowParameterList_{\lbrack \rm{Yield, Await} \rbrack}
Cover〜がPrimaryExpressionから導出されたなら
$ ParenthesizedExpression: ( Expression )
という文法を使ってrefineする
他のsupplemental syntaxを見てみる
全部で5つしかないっぽい
const async = () => {}のようなコードに対応するための定義がありそう
Left-Hand Side expression
代入文の左辺？
カバー文法適用の流れ
1. Pにマッチしたトークン列をNをゴールシンボルとしてパースし直す
Pにgrammatical parameterが渡されていたらNにも引き継ぐ
2. トークン列が一つ残らずパースされて、Nのインスタンス1つになったらパース成功
Nのインスタンス（Pと一対一の対応関係にある）を「PにカバーされたN」と呼ぶ
Nとそこから導出された生成規則のすべてのearly error ruleも適用する
grammatical parameterとは
たぶん $ _{\lbrack \rm{Yield, Await} \rbrack} みたいなやつ
他のところではparameterと呼ばれている
次の節で説明される
unique for a given P
21:06 再開です
(英語) generalize
「一般化」と訳すと「普遍的なルールに従って変換した」みたいなニュアンスが出そう
ここのgeneralizeは本来的にはあんまり関連がないものを実用上の目的でまとめているということなので、ちょっと誤解を招くのでは
「本来的にあまり関連がない」かな？と思いますnoyan.icon
たしかに！yebis0942.icon
「違いがない」→「関連がない」に直しました
(英語) refine
the interpretation of CoverParenthesizedExpressionAndArrowParameterList is refined using the following grammar.
いい訳なかった
辞書的には精錬するとか純化するとか
ドラフト読んでいったほうがいいのでは説
5.1.4 The Syntactic Grammarの説明はDraftで改善されてた
メインブランチにマージされた時点で一定の品質は担保されていると期待できそう
読んだところが後から更新されたら困る？
どちらにしても更新はされるので気にしなくてよさそう
ドラフトなら分割版ページもあるのでよさそう
Firefoxなら全部入りページでも軽いという噂
The first document I found is a snapshot of ESnext. Those snapshots are going to keep happening every year (hence ES2016, ES2017...). My colleague Daniel Ehrenberg, an engineer on V8 and member of TC39, told me that developers should be looking at the spec draft rather than the snapshots. JavaScript engines like V8 have been trying to keep up with the spec draft rather than going from snapshot to snapshot. If you read my previous post in this series, you’ll remember I said something similar about Web specs. Drafts – use them!
5.1.5 Grammar Notation
some terminal symbols
リリース版ではsomeって言ってなかったよね…
A code point in a terminal symbol cannot be expressed by a \ UnicodeEscapeSequence.
code:a.js
var \u0077 = 1; console.log(w); // 1
\u0077hile (0) {} // syntax error
っていうことを言いたいんだろうか？yebis0942.icon
既視感が出てきた
mnemonicとか前回読んでた覚えが
2021版にはmnemonicという単語がないので、当時もドラフト版読んでたらしい