本頁の目次 目次 次頁: 8_Types 前頁: 6_Source_Text
ECMAScript プログラムのソーステキストは最初に、トークン、行終端子、コメントあるいは空白のいずれかである入力要素のシーケンスに変換される。ソーステキストは、次の入力要素としてできるだけ長い文字シーケンスを繰り返しとって、左から右へと走査される。
字句文法には 2 つの目標記号がある。 InputElementDiv 記号は、除法演算子 (/) また除法代入演算子 (/=) が許される構文的文法コンテキストで使用される。 InputElementRegExp 記号は他の構文的文法コンテキストで使用される。
NOTE 構文的な文法内に、除算および RegularExpressionLiteral の両方が構文的文法によって許されるコンテキストが存在する; だが、そういう場合字句文法は InputElementDiv 目標記号を使用するので、そのコンテキスト中でスラッシュ開始は正規表現リテラル開始とは認められない。代替手段として、一つは括弧で正規表現リテラルを囲んでよい。
フォーマット制御のための (マークアップ言語のような) 上位手順がないので、 Unicode 形式制御文字 (例: LEFT-TO-RIGHT MARK や RIGHT-TO-LEFT MARK のような、 Unicode 文字データベース (Unicode Character Database) における "Cf" カテゴリの文字) という制御コードでテキストの範囲のフォーマットを制御する。編集を容易にしまた表示するため、ソーステキスト内でのこれらの許可は有益である。
フォーマット制御文字は ECMAScript プログラムのソーステキストのどの場所に出現してもよい。これらの文字は、字句文法を適用する前にソーステキストから取り除かれる。文字列と正規表現リテラルの処理前にこれらの文字が取り除かれるので、文字列、正規表現内に Unicode 制御文字を入れるには Unicode エスケープシーケンス (セクション 7.6) を使用しなければならない。
空白文字は、ソーステキストの可読性を向上させ、そしてトークン (不可分の字句単位) を互いに分離させるために使用され、それ以上の意味はない。空白は 2 つのトークンの間、また文字列の中に出現できる(リテラル文字列値の一部を形成する意味のある文字と考えられる)。だが、トークンの中に出現することは出来ない。
次の文字が空白と考えられる:
| Code Point Value | Name | Formal Name |
| \u0009 | Tab | <TAB> |
| \u000B | Vertical Tab | <VT> |
| \u000C | Form Feed | <FF> |
| \u0020 | Space | <SP> |
| \u00A0 | No-break space | <NBSP> |
| Other category "Zs" | その他の Unicode "space separator" | <USP> |
空白文字のように、行終端子はソーステキストの可読性を向上させ、そしてトークン (不可分の字句単位) を互いに分離させるために使用される。しかし、空白文字とは違い、行終端子は構文的文法の振る舞いに影響を与える。一般に、行終端子は 2 のトークンの間に出現する。だが構文的文法によって隠される場所がある。行終端子はトークンの中に出現することは出来ない。 not even a string. 行終端子は自動セミコロン挿入の処理にも影響を与える (セクション 7.9)。
空白は 2 つのトークンの間、また文字列の中に出現できる(リテラル文字列値の一部を形成する意味のある文字と考えられる)。だが、トークンの中に出現することは出来ない。
次の文字が行終端子と考えられる:
| Code Point Value | Name | Formal Name |
| \u000A | Line Feed | <LF> |
| \u000D | Carriage Return | <CR> |
| \u2028 | Line separator | <LS> |
| \u2029 | Paragraph separator | <PS> |
コメントは、 1 行または複数行になりうる。複数行のコメントはネストできない。
1 行コメントは LineTerminator 以外の任意の文字を含むことが可能であること、またトークンは常に可能な長さである一般規則により、 1 行コメントは常に、マーカー // からその行の終わりまでの全ての文字で構成される。しかし、行末の LineTerminator は 1 行コメントの内容とはみなされない; それは字句文法によって別々に認識され、構文文法の入力要素のストリームの一部となる。この点がとても重要である。というのは、これは 1 行コメントの有無が自動セミコロン挿入 (セクション 7.9) に影響を与えないということを暗に意味するからである。
コメントは空白のように振る舞い、捨てられるが、 MultiLineComment が行終端子文字を含む場合、構文文法による解析を目的としてコメント全体が LineTerminator と考えられる、
予約語を識別子として使うことはできない。
次のトークンは ECMAScript キーワードであり、 ECMAScript プログラム中で識別子に使うことはできない。
breakcasecatchcontinuedefaultdeletedoelsefinallyforfunctionifininstanceofnewreturnswitchthisthrowtrytypeofvarvoidwhilewith次の語は提出された拡張の中でキーワードとして使用され、その拡張が将来採択される可能性を考え、予約される。
abstractbooleanbytecharclassconstdebuggerdoubleenumexportextendsfinalfloatgotoimplementsimportintinterfacelongnativepackageprivateprotectedpublicshortstaticsupersynchronizedthrowstransientvolatile識別子は、若干の修正を加えた Unicode 標準 (バージョン 3.0 のセクション 5.16) で与えられる文法に従い解釈される。文法は Unicode 標準により指定される文字カテゴリの規範、及び参考情報の両方に基づいている。 Unicode 標準のバージョン 2.1 に指定されるカテゴリの文字は、全ての適合 ECMAScript 実装によってそれらのカテゴリ内として扱われなければならない; しかしながら、適合 ECMAScript 実装は、 Unicode の後のバージョンでのカテゴリ割り当てに基づく追加の合法的な識別子文字を許可してよい。
この標準は Unicode 標準に与えられる文法からある変更を指定する; ドル記号($) 及びアンダースコア (_) は識別子中のどこでも許される。ドル記号は機械的に生成されるコード中のみの使用を意図される。
Unicode エスケープシーケンスは識別子中でも許され、それは UnicodeEscapeSequence (セクション 7.8.4) の CV により算出されるように、識別子中のその場所に一文字を寄与する。 UnicodeEscapeSequence を使って識別子に不正な文字を設定することはできない。言い換えれば、\ UnicodeEscapeSequence シーケンスが UnicodeEscapeSequence の CV に置換されたら、結果は依然として有効な識別子で、正確に元の Identifier と文字の同じシーケンスなければならない。
Unicode 標準に従い規準的に等価である 2 つの識別子は、コードポイントの厳密に同じシーケンスによって表されない限りは等しくない(言い換えれば、適合 ECMAScript 実装は、識別子上でビット比較を行うことのみを要求される)。入ってくるソーステキストがコンパイラに行く前に正規化形式 C に変換されることを意図する。
null リテラルの値 null は、単独の Null 型の値で null と呼ばれる。
Boolean リテラルの値 true は、 Boolean 型の値で true と呼ばれる。
Boolean リテラルの値 false は、Boolean 型の値で false と呼ばれる。
NumericLiteral に直接続くソース文字は、けして IdentifierStart や DecimalDegit ではない。
NOTE 例えば:
3in
はエラーであり、 3 と in の 2 つの入力要素とはならない。
数値リテラルは、 Number 型の値を表す。この値は 2 ステップで判断される: まず、数学値 (MV) がリテラルから派生する; 次に、この数学値が、下に述べるように丸められる。
一旦数値リテラルの厳密な数学値が決定されたら、 Number 型の値に丸められる。数学値が 0 ならば、丸められる値は +0 である; そうではなく、リテラルが DecimalLiteral でなくそのリテラルが 20 を超える有効数字数\でなければ、数値が 20 番目以降の各有効数字を数字 0 へ置換して生成されるリテラルの数学値の数値、または 20 番目以降の各有効数字を数字 0 に置換して生成されるリテラルの数学値の数値、そして 20 番目の有効数字の位置のリテラルの増加、のいずれかでありえる場合、丸められる値は (セクション 8.5 で定義される意味の) 数学値の数値でなければならない。数字はそれが ExponentPart の一部\でなく次の二点のどちらかであれば有効数字 (significant) である。
文字列リテラルは、単引用符または二重引用符で囲まれた 0 個以上の文字である。各文字はエスケープシーケンスによって表されてもよい。
double-quote " or backslash \ or LineTerminator非終端記号 HexDigit の定義は、セクション 7.8.3 に与える。 SourceCharacter はセクション 2 及び 6 で述べる。
文字列リテラルは String 型の値を表す。リテラルの文字列値 (SV) は、文字列値の様々な部分に寄与する文字値 (CV) に関して記述される。この処理の一部として、文字列リテラル内部のいくつかの文字は、セクション 7.8.3 に述べる数学値 (MV) を持つものとして解釈される。
| Escape Sequence | Code Point Value | Name | Symbol |
| \b | \u0008 | backspace | <BS> |
| \t | \u0009 | horizontal tab | <HT> |
| \n | \u000A | line feed (new line) | <LF> |
| \v | \u000B | vertical tab | <VT> |
| \f | \u000C | form feed | <FF> |
| \r | \u000D | carriage return |
<CR> |
| \" | \u0022 | double quote |
" |
| \' | \u0027 | single quote | ' |
| \\ | \u005C | backslash | \ |
NOTE 文字 LineTerminator は、それにバックスラッシュ \ を先行させても、文字列リテラル内には出現できない。 行終端子文字を文字列リテラルの文字列地の一部に置く妥当な方法は、 \n や \u000A のようなエスケープシーケンスを用いることである。
正規表現リテラルは走査時に RegExp オブジェクト (セクション 15.10) に変換される入力要素である。オブジェクトはそれを含むプログラムまた関数の評価の開始前に生成される。リテラル評価はそのオブジェクトへの参照を生成する; それは新規オブジェクト生成はしない。プログラム内の 2 つの正規表現リテラルは、2 つのリテラルの内容がまったく同じであっても、互いに === として比較しない正規表現オブジェクトに評価する。 RegExp オブジェクトは、 new RegExp (セクション 15.10.4) や関数としての RegExp コンストラクタ呼出し (セクション 15.10.3) によって実行時に生成されてもよい。
下の生成規則は正規表現リテラルの構文を記述し、正規表現リテラルの終了の検出に入力要素走査から使用される。 RegularExpressionBody 及び RegularExpressionFlags を構成する文字の文字列は、それ自身がより厳重な文法でそれらを解釈する正規表現コンストラクタに、未解釈で渡される。実装は正規表現コンストラクタの文法を拡張してよいが、 RegularExpressionBody 及び RegularExpressionFlags 生成規則、またはこれらの生成規則によって使用される生成規則を拡張すべきではない。
NOTE 正規表現リテラルは空にはならない; 空の正規表現リテラルをあらわす代わりに、文字 // は 1 行コメントを開始する。空の正規表現を指定するには、 /(?:)/ を用いる。
正規表現リテラルは Object 型の値を表す。この値は 2 ステップで決定される: まず、正規表現の RegularExpressionBody 及び RegularExpressionFlags 生成規則拡張を構成する文字が、それぞれ 2 つの文字列の Pattern と Flags に解析されずに集められる。そして new RegExp コンストラクタが 2 つの引数 Pattern と Flags で呼出され、結果は RegularExpressionLiteral の値となる。 new RegExp 呼出しがエラーを生成するならば、実装は、自由裁量で、プログラム走査中に直ちにエラー報告してもよいし、プログラム実行中に正規表現リテラルが評価されるまでエラーを延期してもよい。
ある種の ECMAScript 文 (空文 (empty statement), 変数文 (variable statement), 式文 (expression statement), do-while 文 (do-while statement), continue 文 (continue statement), break 文 (break statement), return 文 (return statement), turhow 文 (throw statement)) はセミコロンで終了しなければならない。そのようなセミコロンは、ソーステキスト内に常に明示的に出現してよい。しかしながら、簡単にするために、ある位置ではソーステキストからセミコロンを省略してよい。この位置は、それらの位置のソースコードトークンのストリームにセミコロンが自動的に挿入されるという言葉で説明される。
とはいえ、以上の規則を上書きする条件を追加する: セミコロンが結果として空文として解析される場合、またセミコロンが for 文 (セクション 12.6.3) のヘッダ内の 2 つのセミコロンの一つになる場合は、セミコロンは自動的に挿入されない。
NOTE 文法における限定生成規則は下記のみである:
continue [LineTerminator 無し] Identifieropt ;break [LineTerminator 無し] Identifieropt ;return [LineTerminator 無し] Expressionopt ;throw [LineTerminator 無し] Expression ;これらの限定生成規則の実際の効果は、次のとおりである:
continue, break, return, throw トークンが出現し、次のトークンの前に LineTerminator が出現するとき、セミコロンは continue, break, return, throw トークンの後に自動的に挿入される。ECMAScript プログラマへの結果的な実用的助言は:
return 文、また throw 文中の Expression は、return トークンまた throw トークンと同じ行で開始するべきである。break 文、また continue 文のラベルは、 break トークンまた continue トークンと同じ行にあるべきである。次のソース
{ 1 2 } 3
は、ECMAScript 文法において、自動セミコロン挿入規則を以ってしても有効な文ではない。
対照的に、このソース
{ 1
2 } 3
もまた有効な ECMAScript 文ではないが、自動セミコロン挿入によって次のように変換される:
{ 1
;2 ;} 3;
これは有効な ECMAScript 文である。
ソース
for (a; b )
は有効な ECMAScript 文ではなく、自動セミコロン挿入によって変更されない。セミコロンが for 文のヘッダに要求されるからである。自動セミコロン挿入が for 文のヘッダ内の 2 つのセミコロンの 1 つを挿入することはない。
ソース
return a + b
は自動セミコロン挿入によって次のように変換される:
return; a + b;
NOTE 式 a + b は、 return 文によって返される値として扱われない。return トークンから LineTerminator で分離されているからである。
ソース
a = b ++c
は自動セミコロン挿入によって次のように変換される:
a = b; ++c;
NOTE トークン ++ は、変数 b に適用される後置演算子として扱われない。 b と ++ の間に LineTerminator があるからである。
ソース
if (a > b) else c = d
は有効な ECMAScript 文ではなく、その位置に適用する文法の生成規則がないとしても、 else トークンの前への自動セミコロン挿入によって変更されない。自動セミコロン挿入が空文として解析されるからである。
ソース
a = b + c (d + e).print()
は自動セミコロン挿入によって変換されない。 2 行目の括弧式 () は関数呼び出しの引数リストとして解釈できるからである。
a = b + c(d + e).print()
代入文が左括弧で開始しなければならない状況では、自動セミコロン挿入を信頼するより、先行する文の末尾に明示的なセミコロンを提供する方が、プログラマにとってよい発想である。