オスロ
2008年10月28日
OsloはMicrosoftのプロジェクトであり、今週のPDCカンファレンスまで詳細はほとんど明らかにされていませんでしたが、様々な噂が飛び交っていました。分かっていることは、モデル駆動型ソフトウェア開発とドメイン特化言語に関係しているということです。
数週間前、私と私の言語オタクの同僚であるレベッカ・パーソンズは、ドン・ボックス、ジオ・デッラ・リベラ、そしてヴィジャイ・ラジと共に、PDCで発表される内容のプレビューを見ることができ、Osloの舞台裏を垣間見ることができました。非常に興味深いプレゼンテーションであり、Osloが注目すべき技術であると確信するには十分でした。Osloは広義には言語ワークベンチです。ここではこのツールの包括的なレビューを試みるつもりはありませんが、ウォークスルーから得た散漫な印象を述べたいと思います。PDCでの公開リリースに伴い、今後数週間のうちにOsloについてもっと多くの情報が得られるでしょう。私の考えを説明する際に、私の著書のために開発してきた言語を多く使用するので、専門用語が少し難解に感じるかもしれません。
Osloは3つの主要コンポーネントで構成されています。
- テキストDSL用のモデリング言語（現在のコードネームはM）
- グラフィカルDSL用のデザインサーフェス（Quadrant）
- リレーショナルデータベースにセマンティックモデルを格納するリポジトリ（名前はまだありません）。
（これらの名前はすべて現在のコードネームです。マーケティング部門は、「AvalonとIndigo」を「WPFとWCF」に置き換えたのと同じスマートさを使うでしょう。「Windows」を「Windows Technology Foundation」に改名してくれることを願っています。）
テキスト言語環境はブートストラップされ、3つの基本言語を提供します。
- MGrammar：構文指向変換の文法を定義します。
- MSchema：セマンティックモデルのスキーマを定義します。
- MGraph：セマンティックモデルのインスタンスを表すためのテキスト言語です。MSchemaは型を表すのに対し、MGraphはインスタンスを表します。Lisp使いは、MGraphを醜い構文を持つS式と考えるかもしれません。
MGraphではあらゆるモデルを表現できますが、構文はあまり良くないことがよくあります。MGrammarを使用すると、独自のDSLの文法を定義できます。これにより、独自のDSLでスクリプトを記述し、パーサーを構築して、より有用なものに変換できます。
私の本の序章にある状態マシンの例を使用すると、MSchemaで状態マシンのセマンティックモデルを定義できます。その後、（醜い方法で）MGraphを使用してデータを入力できます。構文を定義し、パーサーを駆動するためにMGrammarを使用して、データを入力するための適切なDSLを構築できます。
MGrammarの入力ファイルを受け取り、イメージファイル、つまり.mgxファイルにコンパイルする文法コンパイラ（mgと呼ばれます）があります。これは、ほとんどのパーサジェネレータツールとは異なります。ほとんどのパーサジェネレータツールは、文法を受け取り、パーサにコンパイルする必要があるコードを生成します。代わりに、Osloのツールは文法を解析規則のバイナリ形式にコンパイルします。その後、入力スクリプトとコンパイルされた文法を受け取り、入力スクリプトの構文木のMGraph表現を出力する別のツール（mgx）があります。
コンパイルされた文法をリソースとして独自のコードに追加する方が可能性が高いでしょう。これにより、Osloが.NETフレームワークとして提供する汎用パーサーメカニズムを呼び出し、コンパイルされた文法ファイルへの参照を提供し、メモリ内構文木を生成できます。その後、この構文木をウォークして、好きなように使用できます。私がツリー構築と呼ぶ解析戦略です。
パーサーは構文木を提供しますが、それは多くの場合セマンティックモデルと同じではありません。そのため、通常はツリーをウォークして、MSchemaで定義されたセマンティックモデルにデータを入力するコードを記述します。これが完了したら、そのモデルを簡単にリポジトリに格納して、SQLツールからアクセスできるようにすることができます。複雑な構造には触れませんでしたが、デモではDSLを介してデータを入力し、リポジトリ内の対応するテーブルにアクセスする方法が示されました。
Quadrantを使用してセマンティックモデルインスタンスを操作することもできます。スキーマのグラフィカル表記を定義すると、システムはその表記を使用してモデルインスタンスを投影し、ダイアグラムを作成できます。ダイアグラムを変更してモデルを更新することもできます。オブザーバー同期を使用して、一方の更新が他方を更新するモデルの2つのグラフィカル投影のデモが示されました。このように、Quadrantを使用すると、MetaEditなどのグラフィカル言語ワークベンチと同様のスタイルで作業できます。
Osloの開発中に、Microsoftの他のプロジェクトで使用して、その使用経験を積んできました。これまでの主なものは、ASP、Workflow、Webサービスです。
Mの詳細
私たちはほとんどの時間をテキスト環境を見て過ごしました。コンパイルされた文法をテキスト編集コントロールに接続して、さまざまな補完と強調表示機能を備えた構文認識テキストエディターを提供する方法があります。ただし、MPSなどのツールとは異なり、依然としてテキストエディターです。そのため、テキストのストレッチをカットアンドペーストしたり、テキストを自由に操作したりできます。行った操作を解析する際に問題が発生した場合、ツールは波線を表示しますが、テキスト編集エクスペリエンスは保持されます。
私はこれが好きだと思います。初めて出会ったとき、MPSの「テキストのように見えますが、実際には構造化エディターです」という概念が好きでした。しかし最近、その方法では多くのものを失ってしまうと思うようになり、Osloの作業方法は魅力的です。
彼らが持っているもう1つの優れたテキスト言語ツールは、MGrammarsの作成に役立つエディターです。これは、3つの垂直ペインに分割されたウィンドウです。中央のペインにはMGrammarコード、左側のペインには入力テキスト、右側のペインにはMGrammarで入力テキストを解析したMGraph表現が表示されます。非常に例に基づいています。（ただし、テストとは異なり、一時的なものです。）このツールは、Antlrの機能で、文法ですぐにサンプルテキストを処理する機能に似ています。会話の中で、レベッカはこのスタイルを「逸話的なテスト」と呼んでいましたが、これは私が盗まなければならないフレーズです。
彼らが使用する解析アルゴリズムは、GLRパーサーです。文法構文はEBNFに匹敵し、ツリー構築式の表記法があります。彼らは、他のツールとの整合性を高めるために、レクサーで独自の正規表現表記を使用しています。これは、ISO / Perlの正規表現表記に慣れている私のような人を混乱させる可能性があります。ほとんど似ていますが、迷惑になるほど異なります。
彼らの文法表記の優れた機能の1つは、パラメータ化された規則を簡単に作成できるコンストラクトを提供していることです。事実上、規則サブルーチンを記述できます。規則には、.NETの言語属性と同様に、属性（別名注釈）を付けることもできます。そのため、属性でマークすることで、言語全体を大文字と小文字を区別しないようにすることができます。（興味深いことに、Java構文のように、「@」を使用して属性をマークします。）
文法を実行するデフォルトの方法は、ツリー構築を行うことです。結局のところ、ツリー構築は、入力を処理している間文法によって呼び出されるデフォルトクラスの動作です。このクラスにはインターフェースがあり、このインターフェースを実装する独自のクラスを記述できます。これにより、埋め込み変換と埋め込み解釈を行うことができます。アクションコードは文法内ではなく、この他のクラス内にあるため、コードアクションと同じではありません。アクション内のコードはしばしば文法を圧倒するため、これははるかに優れていると思います。
彼らは、ある言語を別の言語に埋め込み、パーサーを切り替えてこれを適切に処理する機能について少し話しました。Convergeによって探求された領域に向かっています。私たちはこれを深く掘り下げませんでしたが、それは興味深いでしょう。
彼らが言及した興味深い情報は、もともとグラフィカル言語のツールだけを持つことを意図していたということでした。しかし、彼らは、グラフィカル言語は、スキーマの定義を含む多くの問題にはうまく機能しないことを発見しました。そこで彼らはテキストツールを開発しました。
（マーケティング部門への考えがあります。「M」という名前を使い続ける場合、この素晴らしい映画をマーケティングのインスピレーションとして使用できます;-））
比較
明らかに、このツールは、2005年に私が言語ワークベンチと呼んだIntentional SoftwareやJetBrains MPSなどのツールと同じ空間に浮かんでいます。Osloは、当時私が示した言語ワークベンチの定義に完全に適合するわけではありません。特に、テキストコンポーネントは投影エディターではなく、抽象表現（セマンティックモデル）に基づくストレージ表現を使用する必要はありません。代わりに、より従来のスタイルでテキストソースを格納できます。永続的な抽象表現への依存度が低いことは、Xtextと似ています。いつか、言語ワークベンチの定義要素を再考する必要があります。今のところ、XtextとOsloは言語ワークベンチのように感じ、定義を再検討するまでは、それらをそのように扱います。
この比較で特に興味深い点は、OsloとMicrosoftのDSLツールを比較することです。それらは重複する多くの異なるツールであるため、両方に場所があるかどうか疑問に思います。私は漠然とした「彼らは一緒に合う」というフレーズを聞いたことがありますが、まだ納得していません。複数の半競合プロジェクトが開発されている状況（大企業ではよくあること）の1つかもしれません。最終的には、1つが棚上げされる可能性があります。しかし、これについては、企業の政治に大きく依存するため、推測するのは困難であり、誰からでも率直な答えを得るのはほとんど不可能です（たとえ得たとしても、それが率直な答えかどうかを判断するのはさらに困難です）。
Osloがそのいとこと共有する重要な要素は、新しい言語を定義し、それらを統合し、それらの言語のツールを定義するためのツールキットを提供することです。その結果、優れたツールを備えた外部ドメイン特化言語の構文の自由が得られます。これは、外部DSLの主な欠点の1つに対処するものです。
OsloはテキストDSLとグラフィカルDSLの両方をサポートしており、かなり均等にサポートしているようです（ただし、テキストに多くの時間を費やしました）。この点で、MPSおよびIntentional（構造化テキスト）とMetaEdit / MicrosoftのDSLツール（グラフィカル）よりも多様なを提供しているようです。また、Intentional / MPSの高度に構造化されたテキスト入力ではなく、真のフリーテキスト入力を提供するという点で、テキストサポートも異なります。
テキストエディターに接続するコンパイル済み文法を使用することは、DSLスクリプトの入力をサポートするための非常に優れたルートであるように思えます。他のツールでは、完全な言語ワークベンチ機構を用意するか、コード生成を使用してエディターを構築する必要があります。エディターに接続できる文法の表現を渡すことは、それを行うための良い方法だと思います。もちろん、その言語ワークベンチがオープンソースである場合（MPSになると言われているように）、この問題は議論の余地がなくなるかもしれません。
このようなデータをリポジトリに格納する際の一つの大きな問題は、バージョン管理です。チーム全員が単一の共有データベース（チームが共有ドライブ上のコードのコピーを共同編集するのと同じようなもの）で共同作業できるという考えは、無責任に近いように思います。そのため、このアプローチを提案するベンダーには懐疑的な目を向ける傾向があります。Osloチームは賢明にも、テキストファイルを正式なソースとして扱うことを提案しており、これにより通常のバージョン管理ツールを使用することができます。もちろん、多くのMicrosoftユーザーにとって残念なニュースは、このツールがTFS（あるいは、とんでもないことにVSS）であることですが、プレーンテキストファイルをソースとして使用することの大きな利点は、多数あるバージョン管理システムのいずれを使用して保存することもできることです。
私が全体的に気に入ったのは、ほとんどのツールがコード生成とコンパイルではなく、実行時解釈に傾いていることです。従来のパーサー ジェネレーターや多くの言語ワークベンチは、モデルからコードを解釈するのではなく、生成することを前提としています。コード生成は大変結構なことですが、常に厄介な感じがつきまといます。そして、あらゆる種類の問題を引き起こす傾向があります。そのため、私は実行時に重点を置く方を好みます。
わずか数時間だったので、Osloについて広範な判断を下すことはできません。しかし、非常に興味深い技術のように見えるとは言えます。私が気に入っているのは、言語ワークベンチを使用するための良い道筋を提供しているように見えることです。Microsoftが後ろ盾になっていることは大きな意味を持つでしょうが、Longhornについても実現しなかったあらゆる種類のことが約束されていたことを忘れてはなりません。しかし、全体として、これは言語ワークベンチシーンへの興味深い追加であり、DSLをより普及させる可能性のあるツールだと思います。