【しばらく編集不可モードで運営します】 編集(管理者用) | 差分 | 新規作成 | 一覧 | RSS | FrontPage | 検索 | 更新履歴

ECMAScriptHarmony - ECMAScript Harmony

目次

ECMAScript Harmony

この文書について

ECMAScript Harmony

JavaScript の標準化を主導する Ecma の 第 39 技術委員会 (TC39) で, この一年間不 和が続いているのは公知の事実です. 一部のメンバーはECMA-262 の第四版である ES4 を推しています. また別のメンバーは既存の ECMA262 第三版 (ES3) に基くES3.1 仕様を支持しています. 今日, 嬉しい知らせがあります. 不和は解消されました.

7 月末に Oslo で開催された Ecma TC39 の会合はとても生産的なものでした. そして我々が共同作業をするなら, ここ数年を振り返るのは意義のあることでしょう. この会合に先だち, 私は TC39 の議長や ES3.1 と ES4 の代表, 特に Lars Hansen (Adobe), Mark Miller (Google), Wirfs-Brock(Microsoft) と 会議体の価値をまとめ, ロードマップを共通化すべく準備を進めてきました. このメッセージは先の会議での結果を公知しようとするものです. 私はこの成果を "Harmony" と銘打ちました.

要旨

委員会は以下のタスクと結論を支持します.

詳細な声明

会議体の分裂は誰にとっても, 何のためにもなりません. 少なくともそこから現れる言語仕様についてはそう言えるでしょう. この前提に基き, 私は Harmony を提案しています. しかし Harmony は (ES4 関係者の一部にとっては重要である)名前空間の仕様を意図的に 削っています.

言語への小さな変更, 新しいセマンティクスではなく新しい文法を求めるような, 継続的な進化を支持する誰もにとって, これは良いニュースです. これはつまり, 1999 年に行なわれた ES4 の最初の提案のうちのいくつかのアイデアは, これは JScript.NET や ActionScript に様々な形で実装されているものですが, ES の標準にはならないということです. しかし, ES3.1に始まり, より大きく変化し改良された仕様技術を伴いつつそれに続いていく, ES3の統一された後継仕様への協調という恩恵が得られます.

ES4 における名前空間のユースケースのひとつは, (名前空間の intrinsic に よる)アーリーバインディングと, 性能の向上, プログラマの理解しやすさの改善でした. - アーリーバインディングは矛盾する実行時の名前のバインディングがおこらないからです. しかしウェブのようにコードを動的にロードする場面では, アーリーバインディングとレイトバインディングの衝突を避ける 優先順位づけや予約の仕組みは必要です.

加えて複数のオープンな名前空間は, 実装側で更なる著しい工夫をしない限り実行時のコストを負うことになると, いくつかの JS の実装者は指摘しています.

こうした理由から, 名前空間とアーリーバインディングは (以前, この 4 月に あった package と同様) 取り去らざるをえません. これは最終決定です. 将来とりあげる可能性もありません. harmony を成し遂げるために, 我々は「何を入れるか(what's in)」や, 何なら入れられるかというような短期間での改善に集中するだけでなく, 何を入れないか(what's out)の合意にも取り組む必要があります.

名前空間とアーリーバインディングが仕様から外れてしまえば, クラスは lambda-coding + Object.freeze と ES3.1 のその関係機能 というすっきりした(desugar)姿になります. 我々が Oslo で harmonized class の提案として議論したような, 新しいランタイムのセマンティクスをモデル化する必要は, 一切ありません. (我々が議論した内容については, ほどなく wiki ページで公開します.)

クラスの単純化(desugaring)について, 我々は Oslo で詳細に議論しました. その意見交換に際して, 我々は独立した別々の問題を検討しました. クラス, 継承, like パターン, 型の注釈などです. これ以上詳しくは書きませんが, 一つだけ指摘しておきます. 議論には合意と不和の軸がはっきりとありました. こうしたアイデアの幾つかについて委員会が合意に至ってほしいという希望があり, 一番単純な提案から始め, 議論を進めながら合意を保っていくことを全体的として優先していました.

仕様の主要な読者は, 互換性を保ちたくても lambda-conding の権威にはなりたくないでしょうから, lambda-coding が曖昧すぎるならランタイムのヘルパを追加することはあるかもしれせん. しかし 3.1 の仕様でランタイムのセマンティクスを拡張はしないつもりです. 複雑さから規律を守るためです.

セマンティクスを追加する可能性がひとつあります. それはこの言語にある周知のギャップを埋めるためのもので, Mark Miller の助力を得ながら私が概観を固めました: どんな文字列のプロパティ識別子とも等価でない, 新しい Name オブジェクトを作る手段を追加するというものです. 多くのメンバーがこの新しい Name オブジェクトのアイデアに賛成でした.

残された課題もあります. 特にテストができず, ES1 から 3.x に渡って段々と見苦しくなってきた仕様記述の 形式(spec formalism)を取り除くことです. ES4 のように, SML で記述して自己ホストした組込み機能(built-ins)を持つ 参照実装(RI)をつくるというアプローチは, 概ね肯定的に受けとられています. 今のところ異議を唱える人はいません.

我々は RI から名前空間とアーリーバインディングを取り除いています. (この機能は正規(normative)の自己ホストの振舞いを使っています. "ユーザーのコード" が組込み機能の意味を変えないようにするためです.) RI を単純なものにして, ES3.1 プラス, またはマイナスを実装するためです. (自己ホストの組み込み機能はもう少し細工が必要そうです.) この取り組みに関する詳しい説明は近々できると思います.

ES3.1 は getter と setter を標準化します. これは最初 Mozilla で実装され, Apple と Opera にコピーされました. こうしたデファクト標準化の続きは, harmonize 委員会の後続の版で俎上に上がっています.

デファクト標準を取りこむ簡単な標準化については, 良好な反応を受け取っています. 特にブロックスコープの定数に使う新しい var としての let は 3.1 に提案されています. (たしかそうだったはずです.) 式クロージャ(expression closure) のような簡単な単純化や 分割代入(destructuring assignment), そのほか JS1.7 や 1.8 に含まれる機能のうち, 新しいランタイムのいらないものについても, いくつか賛成のコメントがありました.

これらの機能に新しい文法が必要なのは明らかなので, 3.1 以降での "ES-harmony" の大きな改版に回すのが適切でしょう. 文法はユーザーインターフェイスです. これを改善しない理由はありません. 更に, 拡張 ES3 実装間のセマンティクスが交わる部分には衝突があり, 文法の「セマンティクス」の下位互換性は失なわれます. 上位 4 つのブラウザすべてがこうした文法をパースできるとしてもです. (例: ブロック内関数など)

新しい文法の妥当性や (ES3 拡張の) セマンティクスの非互換な変更を考慮すると, これから登場する harmony 対応の版ではオプトインのバージョン処理が欲しくなります. オプトインのバージョン処理に関しては, サーバ側でファイルの拡張子と MIME タイプの対応づけを管理しなければならないという懸念がありました. この懸念は薄れたと私は考えています. (実際のブラウザ,また HTMLT5 と RFC4329 はサーバの送信する Content-Type を考慮しません. ウェブページの作者はバージョンのパラメタを script タグの type 属性に直接書き込むことができます.)

バージョンを選択できる言語内の pragma 指定についての関心もいくらか表明されています. これはパースの途中ですぐにバージョンを切り替えるというものです. これは将来検討すべき課題です.

これは名前空間の除去と同じくらい重要なことですが, 議論の主眼は委員会がビジョンを持っているということです. 言語は文法的に拡張するものであり, 今ある "上位 4 つのうち 3 つのブラウザ" の文法や標準ライブラリ拡張の組合せに 新しいセマンティクスを合わせこもうとするものではないのです.

Waldemar Horwat(Google) も最終日に言いましたが, 会合は画期的なものでした. また長い委員会の中で最も生産的な会合の一つでもありました. 3.1 と Harmony にはやらなければいけないことが多く残っています. しかし我々はようやく, 一つの委員会として歩みを進めるための良き足がかりを得たのです.

/be