(57)【要約】  本主題開示は、データ集約型アプリケーションをコンパクトで使いやすいテキスト形式で書くこと、また、プログラムの単一のコンパイル単位が複数の構文をサポートできるように、データ集約型アプリケーション内の自己定義の構文に従ってデータ集約型アプリケーションを書くことを可能にする、スクリプト言語のための拡張可能な構文に関する。ユーザ定義の構文および他の既存のドメイン固有言語を収容するために、代替の構文をインラインで定義し、次いでプログラム内で使用できるようにする拡張可能な構文を、Ｍに提供する。一実施形態において、その代替の構文を、プログラム内の予め指定された関数のポイントにおいて定義することができる。
2012504826.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのプログラミングモジュールを、宣言型プログラミング言語を用いて生成する方法であって、
コンピューティング装置のメモリ内で、宣言型ソースコードのテキスト入力を受け取るステップ８００であって、同一のプログラム内で、前記宣言型プログラミング言語のネイティブの構文に従って指定されたネイティブのテキスト入力と、前記ネイティブの構文とは異なる構文に従って指定された在外のテキスト入力とを受け取るステップを含むステップ８００と、
前記ソースコード内で前記異なる構文の定義を受け取るステップ８１０と、
前記ソースコードをコンパイルするステップ７５０、８２０であって、前記異なる構文の前記定義に関連する規則を用いて前記ネイティブの構文の規則を拡張し、拡張された構文規則のセットを形成するステップを含むステップ７５０、８２０と
を含むことを特徴とする方法。
【請求項２】
前記コンパイルするステップ７５０、８２０は、前記異なる構文を、ホストプログラミング言語の用語および文法規則に適合するデータ値に変換するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ソースコード内で前記異なる構文の定義を受け取る前記ステップ８１０は、前記ソースコード内で、ネストされた構文のセットの定義を受け取るステップを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記ソースコード内で前記異なる構文の定義を受け取る前記ステップ８１０は、前記ソースコード内で、定義を含むよう範囲を定めた前記異なる構文の定義を受け取るステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記ソースコード内で前記異なる構文の定義を受け取る前記ステップ８１０は、前記ソースコード内で、プログラムの関数の観点から予め固定された位置のセットの１つにおいて、前記異なる構文の定義を受け取るステップを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記ソースコード内で前記異なる構文の定義を受け取る前記ステップ８１０は、前記ソースコード内で、最高レベルの宣言、モジュールメンバの宣言、または式において、前記異なる構文の定義を受け取るステップを含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記コンパイルするステップ７５０、８２０は、
前記異なる構文の前記定義により前記ソースコード内で定義された新しい構文規則を抽出するために、第１のパスによって前記ソースコードを構文解析する第１のステップ８２０と、
少なくとも１回の追加のパスによって前記コードを構文解析して、前記拡張された構文規則に従って前記テキスト入力を抽出する第２のステップ８３０と
を含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記構文解析する第１のステップに続いて意味グラフ構造を生成するステップ７３０と、前記構文解析する第２のステップに続いて生成された抽象ツリー構造を、前記意味グラフ構造にマージするステップ７４０とをさらに含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記構文解析する第１のステップ８２０は、前記ソースコードをスキャンするステップと、少なくとも１つの構文宣言を抽出するステップとを含むことを特徴とする請求項７に記載の方法。
【請求項１０】
前記構文解析する第１のステップ８２０は、前記ソースコードをスキャンするステップと、キーワード「ｓｙｎｔａｘ」で始まる少なくとも１つの宣言を抽出するステップとを含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記構文解析する第２のステップ８３０は、構文宣言を無視するステップを含むことを特徴とする請求項７に記載の方法。
【請求項１２】
請求項１に記載の前記方法に従って、宣言型プログラミング言語のソースコードから少なくとも部分的にコンパイルされたコンピュータ実行可能命令を備えることを特徴とするコンピュータ可読媒体。
【請求項１３】
宣言型プログラミング言語のコンピュータプログラミング構造に基づいて生成されたコンピュータプログラム製品であって、
宣言型ソースコードのテキスト入力を受け取るステップ７００であって、前記ソースコードを表している同一のデータストリーム内に、前記宣言型プログラミング言語の第１の構文に従って指定された第１のテキスト入力と、前記第１の構文と異なる少なくとも１つの第２の構文の少なくとも１つの定義と、前記少なくとも１つの第２の構文に従って指定された第２のテキスト入力とを含むステップ７００と、
前記コンピュータプログラム製品を形成するために、前記データストリームの前記テキスト入力をコンパイルするステップ７５０と
を含む方法から生成されたコンピュータプログラム製品。
【請求項１４】
前記受け取るステップ７００は、前記宣言型ソースコードの同一の式内で、前記第１のテキスト入力と、前記少なくとも１つの第２の構文の前記少なくとも１つの定義を受け取るステップとを含むことを特徴とする請求項１３に記載のコンピュータプログラム製品。
【請求項１５】
前記受け取るステップ７００は、前記第１のテキスト入力と、前記少なくとも１つの第２の構文の前記少なくとも１つの定義を、前記宣言型ソースコードのモジュールレベルの宣言において受け取るステップを含むことを特徴とする請求項１３に記載のコンピュータプログラム製品。
【請求項１６】
前記コンパイルするステップ７５０は、前記第１の構文の構造に対する前記データストリームを構文解析する第１のステップ８２０と、前記少なくとも１つの第２の構文の前記少なくとも１つの定義と、前記少なくとも１つの第２の構文の構造とを識別するステップとを含むことを特徴とする請求項１３に記載のコンピュータプログラム製品。
【請求項１７】
前記コンパイルするステップ７５０は、前記識別された少なくとも1つの定義に基づいて、前記少なくとも１つの第２の構文の構造のための前記データストリームを構文解析する第２のステップ８３０を含むことを特徴とする請求項１６に記載のコンピュータプログラム製品。
【請求項１８】
宣言型ソースコード９１０のテキスト入力を受け取るためのインタフェース９１０、９２０であって、同一のコンパイル単位内に、宣言型プログラミング言語のネイティブの構文に従って指定された第１のテキスト入力と、前記ネイティブの構文とはそれぞれ異なる少なくとも１つの構文に従って指定された第２のテキスト入力と、前記ソースコード内の許容される予め決められた位置に配置された前記少なくとも１つの構文の少なくとも１つの定義とを含むインタフェース９１０、９２０と
メインツリー構造を形成するために前記第１のテキスト入力に渡って先ず構文解析し７１０、前記少なくとも１つの定義と対応する前記第２のテキスト入力とを識別し、後に、前記少なくとも１つの定義に基づいて前記第２のテキスト入力に渡って構文解析し７４０、前記第２のテキスト入力の前記構文解析の出力を前記メインツリー構造にマージするパーサ９２０と
を備えることを特徴とするコンパイラ。
【請求項１９】
前記パーサ９２０は、前記第１のテキスト入力上に渡る前記第１の構文解析に続いて意味グラフ構造を形成し、前記第２のテキスト入力の前記構文解析に続いて出力として生成される抽象ツリー構造を、前記意味グラフ構造にマージすることを特徴とする請求項１８に記載のコンパイラ。
【請求項２０】
前記パーサ９２０は、前記宣言型ソースコードの前記テキスト入力をスキャンし、ネストされた構文のセットの定義を含む少なくとも１つの構文宣言を抽出することを特徴とする請求項１８に記載のコンパイラ。
【発明の詳細な説明】
【技術分野】
【０００１】
本主題開示は、一般に、他の所望の構文（単数または複数）をプログラム内に収容するために、プログラミング言語のコンパイル単位内に拡張可能な構文を有するプログラミング言語に関する。
【背景技術】
【０００２】
背景として、サーバコンピュータのセットが、データの多数の記録またはトランザクションを長期にわたって収集する場合のように、大量のデータをデータベースに格納している場合、他のコンピュータおよびそれらのアプリケーションが、そのデータまたはターゲットとするそのデータのサブセットにアクセスすることを望むかもしれない。そのような場合、他のコンピュータはスクリプト言語から開発されたプログラムを使用して、クエリ演算子といった1つまたは複数の演算子を介して、また様々な従来のクエリ言語を介して、所望のデータをクエリし、そのデータを読み書きし、そのデータを更新し、またはそのデータに他の任意の処理を適用することができる。そのような状況では、データ量は膨大である可能性があり、かつデータを消費するために進化してきたアプリケーションはまさにデータ集約型となる。従って、これらのデータ集約型アプリケーションをコンパクトで人が使いやすいテキスト形式で書くことが、ずっと課題となってきた。
【０００３】
歴史的に見て、この目的のために、リレーショナルデータベースが、大量の記録およびフィールドを体系化するよう進化し、そのような大規模なデータ収集に使用されてきた。かつ、クエリを出しているクライアントまたはアプリケーションに代わって、リレーショナルデータベースまたは分散型データベースのセットからデータを取り出すようデータベース管理ソフトウェアに命令する、ＳＱＬ（ｓｔｒｕｃｔｕｒｅｄ  ｑｕｅｒｙ  ｌａｎｇｕａｇｅ）および他のドメイン固有言語といった様々なデータベースクエリ言語が、発展してきた。しかし、概して、そのような言語が開発された特定の目的のために、およびそれらの言語が動作するよう意図されたコンテキストのために、様々なドメイン固有の制限の中で、そのような言語は、一言で言えば、充分な一般性を備えることができず、構文的に複雑な構造の重要性を高くし、直観的表現の重要性を低くすることとなった。
【０００４】
しかし、一般化された、データ集約型アプリケーションにとって使用しやすいプログラミング言語を構築することによりこの問題へのソリューションを与えると、そのプログラミング言語をまさに使用することにより、必然的に、多くの開発者がすでに慣れており好んでいる複雑なドメイン固有の構文構造を放棄することとなる。このため、今日開発に単一言語を選択するということは、その言語の構文、そしてその言語のみを使用することを暗示している。
【０００５】
さらなる背景として、例えば、システム管理、再保険、税法、野球統計、特許請求の範囲といった、特定のドメインからのデータを記述する場合、たいてい、そのドメインに固有の用語および文法規則のセットが存在する。その用語および文法規則のセットは、「言語」と呼ばれる。プログラミング言語も、プログラミング言語そのものにきわめて固有の用語および文法規則が組み込まれている。ソフトウェア技術分野に精通する人は認識できるように、ＦＯＲＴＲＡＮでプログラムを書くことには、同一または同様のプログラムをＣ＋＋で書くのとは異なるソースコードを書くことが伴う。人間の言語と同様に、実際には、ある言語が別の言語のある特定の表現能力を所有していない、またはその逆もまた同じであるような異なる言語のプログラム間で、変換する方法は存在しないであろう。
【０００６】
これに関して、ドメイン固有の概念をプログラミング言語で記述することは、冗長かつエラーを起こしやすく、そのことが、自らのドメイン内では開発にうまく適しているが他のドメイン内では必ずしもそうでもないＤＳＬ（ｄｏｍａｉｎ  ｓｐｅｃｉｆｉｃ  ｌａｎｇｕａｇｅ）の開発の動機付けとなっている。従来、ＤＳＬは２つのカテゴリ、すなわち、外部と内部に分類されている。外部ＤＳＬは、ドメインの用語および文法規則に充分カスタマイズすることができる。内部ＤＳＬは、ホストプログラミング言語の文法規則を使用し、次いでそれらの規則内でまたはそれらの規則に加えて語彙を開発する。外部ＤＳＬはより簡潔であるが、それらが定義により外部的であるため、ホストプログラミング言語および関連ツールの利点の多くを失う。内部ＤＳＬは、ホスト言語の利点を保持するが、ホスト言語の文法規則の支配下で構築されるので、より冗長であり、エラーも起こしやすい。
【０００７】
さらに、言語の構文がいかにコンパクトで使用しやすいとしても、異なる背景、経験、文化などを有する異なる開発者は、概念上データを異なるように見るかもしれない。２人の異なる人が、「自然に」または概念上、データをいかに異なるように見るかの例として、アメリカ人は一般的に、人の名前の名を先、姓を後に書くが、外国では、その逆で姓を先に書くところもある点を考えてみよう。同様に、日−月−年と並べることを好む国もあるが、米国では、月−日−年という表記を好む。このように、どのような構文が最終的に決定されようとも、プログラム内のデータを見たりデータについて語る上で好まれる方法に適応できる柔軟性が必要である。
【０００８】
マクロ展開を使用してマクロを特定の出力シーケンスにインスタンス化することができ、一部の言語ではサポートされているが、マクロがその言語でいかに定義されるかの構文は、ネイティブ言語により固定されており、ユーザが望むようにカスタマイズすることはできない。
【０００９】
図１は、この問題への従来のアプローチを一般的に示す。一般的なコンパイルチェーン（多くの詳細は無視する）において、プログラム１００をあるプログラミング言語で書き、コンパイラ１１０がプログラム１００をコンパイルし、コンパイルの結果がオブジェクト表現１２０である。これに関して、プログラム１００は一般的に単一の構文に従っている。その構文が正しくない場合、プログラム１００を正しくコンパイルできない。しかし、プログラム１００において複数の構文を達成するために、従来の解決法の１つは、本質的にコンパイラ１１０がプログラム１００のある特定の構造をどのように置き換えるべきかを指定する、プログラム１００の外部にある別個のファイル１３０を、それがコンパイラには単一の構文として見えるように入力することであった。
【００１０】
しかし、プログラム１００をその構文の定義から分離することには、本質的に問題がある。第１に、規則１３０のいずれかが変更または改訂された場合、プログラム１００はそれ以上動作できない。第２に、規則１３０が、ネットワークの停止、削除、移動などによりアクセス不能または利用不可能になった場合、プログラム１００はそれ以上動作できない。従って、開発者が様々な構文を望む場合、しかも開発者によって修正、削除、移動、忘れられた場合などに機能停止する可能性があるという外部依存性のない方法で使用したい場合には、開発者が使用しなければならない構文を制限しない大規模なデータ処理言語のためのコンパクトなプログラミング言語が望まれる。
【００１１】
現在のプログラミング言語および対応するシステムについての上述の背景情報および欠点は、単に、従来のプログラミング言語の背景情報および問題のいくつかの概観を示すよう意図したものであり、包括的であることを意図しない。従来のシステムにおける他の問題、およびそれに対応する本明細書に説明する様々な非限定的実施形態の利点は、以下の説明を概観するとさらに明らかになるであろう。
【発明の概要】
【００１２】
より詳細な説明および添付図面を伴って以下に続く例示的な非限定的実施形態の様々な態様を、基本的または一般的に理解できるよう支援するために、本明細書に簡略化した概要を与える。しかし、本「発明の概要」は、広範囲または包括的な概観として意図するものではない。むしろ、本「発明の概要」の唯一の目的は、以下に続く様々な実施形態のより詳細な説明の前置きとして、簡略化した形で、いくつかの例示的な非限定的実施形態に関するいくつかの概念を提示することである。
【００１３】
データ集約型アプリケーションをコンパクトで人が使いやすいテキスト形式で書くこと、また、プログラムの単一のコンパイル単位が複数の構文をサポートできるように、データ集約型アプリケーション内の自己定義の構文に従ってデータ集約型アプリケーションを書くことを可能にする、スクリプト言語のための拡張可能な構文を、様々な実施形態で提供する。一実施形態において、スクリプト言語は、データ集約型プログラムのオーサリングに適している、Ｍｉｃｒｏｓｏｆｔ社により設計された「Ｍ」プログラミング言語といった、宣言型プログラミング言語である。ユーザ定義の構文および他の既存のドメイン固有言語を収容するために、代替の構文を例えばインラインで定義し、次いでプログラム内で使用できるようにする拡張可能な構文を、Ｍに提供する。一実施形態において、その代替の構文を、プログラム内の予め指定された関数のポイントにおいて定義することができる。
【００１４】
以下に、これらおよび他の実施形態をより詳細に説明する。
【００１５】
様々な非限定的実施形態を、以下の添付図面を参照してさらに説明する。
【図面の簡単な説明】
【００１６】
【図１】コンパイラによりプログラムのプログラミング構文を変換するための外部規則を適用する従来のシステムを示す図である。
【図２】本明細書で１つまたは複数の実施形態において説明するように、プロブラミング言語のための拡張可能な構文を示すブロック図である。
【図３】プログラム内で共に使用される、ネイティブの構文に対する代替の構文のインライン定義を有するプログラムを示すブロック図である。
【図４】１つまたは複数の実施形態に従う、新しい構文のための予め定義された様々な挿入ポイントを示すブロック図である。
【図５】１つまたは複数の実施形態に従う、別の新しい構文内にネストされる新しい構文の様々な態様を示すブロック図である。
【図６】１つまたは複数の実施形態に従って、プログラム内で新しい構文の範囲を定めることを示すブロック図である。
【図７】１つまたは複数の実施形態に従う、例示的な非限定的コンパイルプロセスを示すフロー図である。
【図８】１つまたは複数の実施形態に従う、オブジェクトコードを生成する例示的な非限定的プロセスを示すフロー図である。
【図９】様々な実施形態に従う、代表的なプログラミング言語により定義される宣言型モデルの例示的プロセスチェーンの図である。
【図１０】記録指向の実行モデルに関連する型システムの図である。
【図１１】本発明の一実施形態に従う、制約ベースの実行モデルに関連する型システムの非限定的な図である。
【図１２】順序化実行モデルに従うデータストレージの図である。
【図１３】順序非依存実行モデルに従うデータストレージの非限定的な図である。
【図１４】本明細書に説明する様々な実施形態を実装することができる例示的な非限定的ネットワーク環境を表すブロック図である。
【図１５】本明細書に説明する様々な実施形態の１つまたは複数の態様を実装することができる、例示的な非限定的コンピューティングシステムまたは例示的な非限定的オペレーティング環境を表すブロック図である。
【発明を実施するための形態】
【００１７】
＜概観＞
とりわけ「背景技術」に論じたように、プログラミング言語において複数の構文を達成する従来のシステムは、コンパイラによって構造を変換するために、完全に外部の規則および定義を包含してきた。しかし、プログラムとその構文の定義をばらばらにすることは、「背景技術」に論じたような様々な理由から、良くない考えである。
【００１８】
１つには、先行の試みにおける制限を考慮して、および１つには、Ｍｉｃｒｏｓｏｆｔ社により開発されたＭプログラミング言語（または、略して「Ｍ」）といった宣言型プログラミング言語の利点を活用して、プログラミング言語の構文をプログラム自体の内で拡張する拡張可能な構文を有する、宣言型プログラミング言語の様々な非限定的実施形態を、本明細書に説明する。
【００１９】
Ｍは、Ｍｉｃｒｏｓｏｆｔ社により設計されたプログラミング言語であり、データ集約型プログラムのオーサリングに適している。本明細書に説明する様々な非限定的実施形態において、コードを、言語のインメモリ表現に対して直接開発するか、またはソースコードからのインメモリ表現に変換することができる。様々な非限定的実施形態において、システム、アプリケーション、およびプログラムは、プログラム内で定義された複数の構文に従うコードを生成し、自動的に認証することができる。
【００２０】
Ｍ中間表現（ＭＩＲ）はＭのモジュールのインメモリ表現である。ＭＩＲはデータ指向型のオブジェクトモデルであり、Ｍのコンパイル単位の構文への対応度が高いオブジェクト初期化構文を使用して簡単に構築できるよう設計されている。ＭＩＲ内の型は、Ｍのコンパイル単位の要素を表すプロパティのみから成り、固有の振る舞いは含まない。全ての振る舞い（型チェック、名前解決、コード生成）を、ＭＩＲの外部にあり、入力としてＭＩＲのグラフを受け入れる方法として実装する。
【００２１】
これに関して、Ｍプログラミング言語は、以下により詳細に述べるが、コンパクトで人が理解可能な表現に適した宣言型プログラミング言語であり、かつ有利なことに、フラッシュストレージ、リレーショナルデータベース、ＲＡＭ、外部ドライブ、ネットワークドライブなど、どれであれ、基礎となるストレージ機構からは独立した、データ集約型アプリケーションを作成し修正するために有効な構造を含む。「Ｍ」は、時々「Ｄ」プログラミング言語とも呼ばれるが、一貫性のため、本明細書ではＤには言及しない。
【００２２】
Ｍプログラミング言語を、Ｍのソースコード、Ｍの抽象構文ツリー、Ｍのグラフ構造などに関して本明細書に説明する様々な実施形態のコンテキストとして与えるが、誤解を避けるために、当然のことながら、本発明は、ネイティブ言語としてＭプログラミング言語に限るものではない。従って、当然のことながら、本明細書に説明する様々な実施形態は、プログラム自体の内でそれ自体の構文を拡張可能であることに関して、Ｍと同一または同様の能力を有する任意の宣言型プログラミング言語に、適用することができる。
【００２３】
従って、様々な非限定的実施形態において、本発明は、Ｍプログラミング言語といった宣言型データスクリプト言語のための拡張可能な構文を提供し、その結果、他のプログラミング言語またはユーザ定義の言語の他の構文を、単一のプログラムまたはコンパイル単位内に収容することができるようになる。これに関して、Ｍのプログラミング構造を、コンパイラが受け取った所与のソースコードのために生成された１つまたは複数の抽象構文ツリーに基づく半構造化グラフデータとして、効率的に表すこともでき、かつ有利なことに、ソースコードを複数の構文に従って指定することができる。
【００２４】
以下は、ＰｅｒｓｏｎをＭプログラミング言語で名と姓を有する型として定義することができる方法、Ｐｅｏｐｌｅを１つまたは複数のＰｅｒｓｏｎとしていかに定義することができるか、およびＰｅｏｐｌｅがＳｅｒｅｎａ  Ｗｉｌｌｉａｍｓと名づけられたＰｅｒｓｏｎをいかに含むかの例である。誤解を避けるため、「Ｍ＞＞＞」はカーソル表現、すなわち、スクリプト環境のアーチファクトである。
【００２５】
2012504826.tif 000003
【００２６】
結果として、Ｐｅｏｐｌｅを以下の通り述べるには、実質的には、定義されたＰｅｒｓｏｎのデータを列挙するよう求め、その結果Ｊｏｓｈ  Ｗｉｌｌｉａｍｓの定義となる。
【００２７】
2012504826.tif 000004
【００２８】
同様に、Ｐｅｏｐｌｅ．Ｆｉｒｓｔを以下の通り述べるには、実質的には、定義されたＰｅｒｓｏｎのデータを列挙するよう求め、その結果Ｓｅｒｅｎａの定義となる。
【００２９】
2012504826.tif 000005
【００３０】
ここまでは、Ｍ言語のホストドメインの構文のみを使用しているが、Ｃｏｎｔａｃｔｓと呼ばれる言語で、Ｐｅｒｓｏｎに関する以下の新しい構文を指定またはインポートすることにより、次のようになる。
【００３１】
2012504826.tif 000006
【００３２】
次いで、以下の新しい式が有効となり、容易に認識できるように、それらはＭプログラミング言語の対応する式より直観的である。なぜなら人間は、他の任意の構文が介在することなく、人々が、名が先、姓が後に呼ばれるドメインに、慣れているからである。従って、より多くのＰｅｒｓｏｎを、Ｃｏｎｔａｃｔｓ言語で以下のように定義することができる。
【００３３】
2012504826.tif 000007
【００３４】
次いで、ホストドメインで指定したＰｅｒｓｏｎ、およびＣｏｎｔａｃｔｓ言語ドメインで指定した上記３人に基づき、Ｐｅｏｐｌｅの列挙を要求する式は以下のようになる。
【００３５】
2012504826.tif 000008
【００３６】
７文字より文字数の多い姓を有するＰｅｏｐｌｅのみを要求する式といった、Ｐｅｏｐｌｅよりもっと複雑な式を構築することもできる。すなわち、
【００３７】
2012504826.tif 000009
【００３８】
上述の例は、比較的簡単な例であるが、他の言語および規則の範囲内で表現を可能にする言語の能力を知ることができよう。様々な実施形態を以下にさらに詳細に説明する。
【００３９】
＜データスクリプト言語のための拡張可能な構文＞
上述のように、様々な非限定的実施形態において、本明細書で例示のために使用するＭプログラミング言語（時々Ｄプログラミング言語とも呼ばれる）といった、宣言型プログラミング言語のための拡張可能な構文を提供するが、実施形態はＭ言語に限るものではない。
【００４０】
様々な実施形態において、プログラミング言語は、拡張可能なプログラミング言語を用いて、特定のドメイン（単数または複数）からの規則で、それ自体の用語および文法規則を拡張することができ、そのようなドメインは、ユーザによって定義されるカスタムのドメイン、または既存のドメインであることができる。利点は、外部ＤＳＬ（また在外言語）の簡潔さおよび正確さを、ホストプログラム自体に在外言語の定義を含むことにより、ホストプログラミング言語の特徴およびツーリングと組み合わせることができることである。
【００４１】
このように、用語および文法規則を定義する能力を、特定のドメインに対するホストプログラミング言語（ＤＳＬ）内に与える。これに関して、ホストプログラミング言語の用語および文法規則を拡張して、ＤＳＬの新しい規則を宣言する同一ファイル内で、ＤＳＬを使用し、そのファイルを内蔵のコンパイルユニットとしてコンパイルすることができるようにする。以下にさらに詳細に例示する様々な実施形態において、ホストプログラミング言語は、ホストプログラミング言語がホストのソースコードと共にコンパイルできる統一表現に従って、ＤＳＬからのデータを提供する。
【００４２】
図２の概略図に示すように、開発者２００が、拡張可能な構文を有する宣言型プログラミング言語に従って、プログラムコード２１０を作成する。コード２１０に使用するプログラミング言語にサポートされているネイティブの構文２１２に加えて、ユーザは、異なる構文２１４を定義するか、または別の既存のＤＳＬを指定することができる。結果として、コンパクトで使いやすい表現（ネイティブプログラミング言語の利点）に従って、および所望により在外の構文に従っても指定される、ソースコード２２０を生成することができ、それによりプログラムに多くの柔軟性を与えることになる。このように、ホスト言語の構文をユーザ好みのドメインまたは既存のＤＳＬに変化させるために、自己修正の文法を、ホストプログラミング言語に提供することができる。
【００４３】
図３は、本概念を例示する仮想プログラム３００を示す。１つのファイル３００において、先ず、ネイティブの構文に従うプログラミング構造３１０がいくつか現れることが可能である。次いで、新しい構文の定義３２０を見つけることができる。次いで、新しい構文に従うプログラミング構造３３０を見つけることができ、ネイティブ言語内のプログラミング構造３４０が再び続く。これらの構造が現れる順序はＭプログラミング言語においてはとりわけ重要というわけではなく、ネイティブの構文および新しい構文をプログラム自体の内で定義し使用することができることは、興味深い。異なるＭのプログラムは、他の構文などを使用することができる。
【００４４】
非限定的一実施形態において、実装のメカニズムには２つ段階を含む。  
段階１：全てのファイルを構文解析し、新しい構文規則を抽出し、次いでこれらの規則でホスト言語を拡張する。  
段階２：ドメイン固有の用語を探す２回目に全てのファイルを構文解析し、次いで、その構文解析の結果を、統一データ表現、すなわちＭの意味グラフで返す。
【００４５】
様々な実施形態において、ホスト言語内での他の言語の使用をより実現可能にする様々な特徴を与えることによって、拡張可能な構文を管理可能にする。
【００４６】
例えば、図４に示す一実施形態において、ホストプログラミング言語で書かれたプログラム４００には、ユーザが新しい構文４４０を挿入する、予め定義された拡張性ポイントを含み、その拡張性ポイントには、コンパイル単位の挿入ポイント４１０、モジュールメンバまたは最高レベルの宣言の挿入ポイント４２０、および式の挿入ポイント４３０を含むが、これらに限らない。構文の定義をこのようにホストの構文に組み入れるが、それはこの目的のためにホストの構文内で明示的に指定された場所においてホストの構文に寄与することによる。上述のように、例には、ＣｏｍｐｉｌａｔｉｏｎＵｎｉｔ、ＭｏｄｕｌｅＭｅｍｂｅｒＤｅｃｌａｒａｔｉｏｎ、およびＥｘｐｒｅｓｓｉｏｎを含む。構文定義をこのように、限られたコンテキストで適用／使用し、それらが寄与するホストの定義の構文カテゴリにより制御する。
【００４７】
図５に示す別の実施形態において、プログラム５００には、ネイティブの構文に従うプログラミング構造５１０、および次いで新しい構文の定義５２０を含む。これに関して、新しい構文５２０自体は、ネストされた構文５３０を介して別のドメインに自らを拡張する。この点において、簡単なネストされた関係を示しているが、ネイティブの言語の構文を拡張するための規則および構文の解析は、言語の任意の階層関係を介して達成することができる。次いで、様々な構造５４０、５５０が、２つ（またはそれ以上）の異なる新しい言語を関与させる新しい／ネストされた構文の規則に従う５４０か、またはホスト言語の構文の規則に従う５５０かのいずれかによって、プログラム５００内に現れることが可能である。
【００４８】
このように、構文定義がそれらのホストの構文から拡張可能な定義を構築し、このように再公開する場合、または構文定義自体が明示的に指定された拡張性ポイントを有する場合、構文定義は自ら拡張可能である。一例として、カスタムの構文がＥｘｐｒｅｓｓｉｏｎを構築する場合が挙げられ、従ってＥｘｐｒｅｓｓｉｏｎに寄与する拡張構文のネストされた使用を受け入れることができる。
【００４９】
構文定義はまた、例えば型といった、含んでいる定義まで範囲を定めることができ、そのためその含んでいる定義を任意に適用／使用することにより、拡張された構文のネストされた使用が可能となる。
【００５０】
2012504826.tif 000010
【００５１】
これは、図６に概念的に示しており、図６では、ネイティブ言語内のプログラミング構造６１０を有するプログラム６００には、新しい構文の範囲または新しい構文が影響を及ぼす範囲が場所６３０に限られ、場所６４０には及ばないということを関数的に意味する、範囲を定めた定義を有する新しい構文を含む。例えば、上述の例において、新しいＰｏｉｎｔ言語をｔｙｐｅ  Ｐｏｉｎｔの値と共に使用できるが、新しい構文を、ｔｙｐｅ  Ｃｏｏｒｄｉｎａｔｅ、または他の如何なる構造に対しても使用することはできない。それどころか、構文は、それ自体が構文を拡張する対象の式に限られる。
【００５２】
図７は、複数の言語の定義および構文の使用を有するプログラムをコンパイルするプロセスを示す。７００において、Ｍのファイルを複数の言語の構文を有するソースコードで指定する。７１０において、プログラムを最初にネイティブ言語に関して構文解析し、実質的には、在外言語の構造がどこに追加情報を集めるべきかを示し、Ｍｇｒａｐｈを先ず構築し、次いで精密化する。正確ではないが、外国語の単語を含む英語の散文に例えられよう。人は先ず英語を読み、知らない外国語の単語がいくつかあることを気に留めるであろう。次いで、その散文の他の場所にある語彙集を使用して、一度識別したその外国語の単語の意味を後に解決することができる。
【００５３】
７２０において、簡略化した形式のバインディングおよび型チェックを、プログラム内の理解された構造または既知の構造にわたって行い、７３０において、構造的な抽象構文ツリー（ＡＳＴ）のセットを出力する。７４０において、追加の構文解析作業を必要とするそのツリーの未知の部分を識別し、コンパイラがこれらに対して、その言語の仕様および構文に基づき追加の構文解析を実施する。このステップでの出力は再び構文ツリーであり、その構文ツリーを７３０において形成されたメインツリーにマージする。在外の構造は、構文の意味を決定するためにツリーの上を何度もパスする必要があるためにネストされることが可能だが、その在外の構造全てを解析すると、結果は、以下の一般的なコンパイルのステップに従ってコンパイルされるＭの意味グラフ構造となる。
【００５４】
図８は、１つまたは複数の実施形態において、ソースコードからオブジェクトコードを生成する代表的なプロセスのフロー図である。８００および８１０において、ネイティブの構文、少なくとも１つの異なる構文、およびコード内に少なくとも１つの異なる構文の定義を有するコードを受け取る。８２０において、その少なくとも１つの異なる構文の定義によりソースコード内で定義された新しい構文規則を抽出することによって、そのコードを構文解析し、ネイティブの構文を拡張し、拡張された構文を形成する。必要があれば、８３０において、拡張された構文規則に従ってテキスト入力を抽出するために、少なくとも１回の追加のパスによって、そのコードを構文解析し、ネストされた構文を詳しく調べる。
【００５５】
上述の概念の例として、行０００〜０５８がＭプログラミング言語で書かれたプログラム全体を構成する、以下のプログラムについて考察する。
【００５６】
2012504826.tif 000011
【００５７】
2012504826.tif 000012
【００５８】
2012504826.tif 000013
【００５９】
上記の例では、ドメイン固有の構文はない。行０３７〜０５７はデータ構造を定義し、行００４〜０３５はデータ値を定義し、それらデータ値はそれらの構造に適合する。留意すべき点は、角括弧［］が、構文解析され式として格納された式を示すことである。
【００６０】
上述のように、上記プログラムはドメイン固有の構文を含まない。比較しやすいように、以下は、本明細書における１つまたは複数の実施形態に従う構文拡張を有する同一言語のプログラムであり、行００１〜０７６がプログラム全体を定義する。
【００６１】
2012504826.tif 000014
【００６２】
2012504826.tif 000015
【００６３】
2012504826.tif 000016
【００６４】
2012504826.tif 000017
【００６５】
上記のプログラムでは、行０５４〜０７５が第１の例のようにデータ構造を定義し、行００３〜０２０がドメインの構文内のデータ値を定義する。行０２１〜０５０がこのドメインに固有の用語および文法規則を定義するが、このドメインは同時に用語“ｒｕｌｅ”を使用する。構文の宣言はそのドメインに固有のテキストを、プログラミング言語が要求する正確な構造へ変換する。そして次に、行５２がドメインの規則をプログラミング言語の規則に追加する。具体的には、ドメインの規則がプログラミング言語のＤｅｃｌａｒａｔｉｏｎ規則を拡張する。
【００６６】
本例では、コンパイラの第１の段階で、ファイルをスキャンし、構文宣言を抽出する。各構文宣言は「ｓｙｎｔａｘ」で始まり、「；」で終わる。他のテキストは全て無視される。これらの構文宣言を処理してパーサに加えると、ファイルは再び構文解析され、テキスト全てが認識される。この第２のパスにおいて、構文宣言を無視し、ドメイン固有の構文（例えば、“ｒｕｌｅ”、“ｒｕｌｅｓｅｔ”）をホストプログラミングの言語の用語および文法規則に適合するデータ値に変換する。
【００６７】
プログラム自体の内で別の言語を使用するホストプログラミング言語の別の例は、先ず在外言語Ａを使用してデータを定義し、次いで言語Ａを定義し、次いでプログラムに適用し、かつ言語Ａに部分的に基づくいくつかの型を定義する以下のモジュールＭである。
【００６８】
2012504826.tif 000018
【００６９】
2012504826.tif 000019
【００７０】
2012504826.tif 000020
【００７１】
2012504826.tif 000021
【００７２】
このとき、言語Ａは、ＣｏｍｐｉｌａｔｉｏｎＵｎｉｔに寄与し、かつ、おそらくスカラー式を超えてＭの構文カテゴリのいずれもおそらく使用しない構文拡張の例である。
【００７３】
＜例示的宣言型プログラミング言語＞
誤解を避けるため、Ｍプログラミング言語といった宣言型プログラミング言語に関してこのサブセクションで与える追加のコンテキストは、包括的ではないが非限定的とみなされるべきである。以下に説明する擬似コードの断片の特定の例は、例示および説明のためのみであり、様々な詳細を上述した宣言型プログラミング言語のための拡張可能な構文の実施形態を制限するものとみなすべきではない。
【００７４】
図９において、Ｍプログラミング言語に基づくモデルといった、宣言型モデルの例示的プロセスチェーンを提供する。図示したように、プロセスチェーン９００には、コンパイラ９２０、パッケージ化コンポーネント９３０、同期化コンポーネント９４０、および複数のリポジトリ９５０、９５２、・・・、９５４の結合を含む。そのような実施形態内で、コンパイラ９２０に入力するソースコード９１０は、Ｍプログラミング言語といった宣言型プログラミング言語でオーサリングされた宣言型実行モデルを表す。例えば、Ｍプログラミング言語を用いて、ソースコード９１０により具現化された実行モデルは、制約ベースの型付けまたは構造的な型付けに有利に従い、および／またはコードの開発を簡略化するために、順序非依存実行モデルまたは非順序化実行モデルを有利に具現化する。
【００７５】
コンパイラ９２０はソースコード９１０を処理し、各ソースコードに対する処理後の定義を生成することができる。他のシステムが命令型フォーマットへのコンパイルを実施するが、ソースコードの宣言型フォーマットは、変換されても維持される。パッケージ化コンポーネント９３０は、処理後の定義を、Ｍプログラミング言語の場合Ｍ＿Ｉｍａｇｅファイルといった、特定のリポジトリ９５０、９５２、・・・、９５４にインストール可能な画像ファイルとしてパッケージ化する。画像ファイルには、必要なメタデータの定義、およびそれらの宣言型ソースモデルとともに複数の変換されたアーチファクトを格納する拡張可能なストレージを含む。例えば、パッケージ化コンポーネント９３０は、特定のメタデータプロパティを設定し、画像ファイル内のコンテンツ部分として、コンパイラの出力アーチファクトとともに宣言型ソース定義を格納してもよい。
【００７６】
Ｍプログラミング言語を用いて、パッケージ化コンポーネント９３０によって使用されるパッケージ化フォーマットは、ＥＣＭＡ  Ｏｐｅｎ  Ｐａｃｋａｇｉｎｇ  Ｃｏｎｖｅｎｔｉｏｎｓ（ＯＰＣ）標準に適合する。この標準が本質的に、圧縮、グループ化、署名などのような特徴を提供することは、当業者には容易に理解できるであろう。この標準はまた、周知のプログラミングモデル（ＡＰＩ）を定義し、それにより画像ファイルを標準的なプログラミングツールを介して操作できるようにする。例えば、．ＮＥＴ  Ｆｒａｍｅｗｏｒｋにおいて、ＡＰＩを「Ｓｙｓｔｅｍ．ＩＯ．Ｐａｃｋａｇｉｎｇ」ネームスペース内で定義する。
【００７７】
同期化コンポーネント９４０は、画像ファイルを管理するために使用できるツールである。例えば、同期化コンポーネント９４０は、画像ファイルを入力として取り入れ、それを関連する画像ファイルのセットとリンクすることができる。途中または後に、パッケージ化されたアーチファクトを抽出し、それらを処理し、同一の画像ファイル内にさらなるアーチファクトを加えることによって、画像ファイル上で動作する支援ツール（リライタ、オプティマイザなど）が、いくつか存在することも可能である。これらのツールは、例えばインテグリティおよびセキュリティを保証するために画像ファイルにデジタル署名するなど、画像ファイルの何らかのメタデータを操作して、画像ファイルの状態を変更することもできる。
【００７８】
次に、展開ユーティリティが画像ファイルを展開し、インストールツールが画像ファイルをリポジトリ９５０、９５２、・・・、９５４内の稼動中の実行環境にインストールする。画像ファイルを展開すると、エクスポート、ディスカバリ、サービス、バージョニング、アンインストールなどを含む、様々な展開後のタスクの対象となることができる。Ｍプログラミング言語を用いて、パッケージ化フォーマットがこれら全ての動作に支援を提供する一方、パッケージ化フォーマットは、セキュリティ、拡張性、スケーラビリティ、および性能のような企業レベルの業界要件にも依然合致している。一実施形態において、リポジトリ９５０は、ＲＤＢＭＳ（ｒｅｌａｔｉｏｎａｌ  ｄａｔａｂａｓｅ  ｍａｎａｇｅｍｅｎｔ  ｓｙｓｔｅｍ）の集合であることができるが、任意のストレージを収容することができる。
【００７９】
一実施形態において、本明細書に説明する方法は、制約ベースの型システムを有するプログラミング言語を用いて動作可能である。そのような制約ベースのシステムは、従来の名目の型システム（ｎｏｍｉｎａｌ  ｔｙｐｅ  ｓｙｓｔｅｍ）で単に利用可能なだけではない機能を提供する。図１０〜１１では、名目型付き（ｎｏｍｉｎａｌｌｙ  ｔｙｐｅｄ）実行システムを、本発明の実施形態に従う制約ベースの型付き実行システムと比較する。図示したように、名目のシステム１０００は各値に特定の型を割り当て、一方、制約ベースのシステム１０１０における値は、無限数の型のいずれにも一致することができる。
【００８０】
名目型付き実行モデルと、Ｄプログラミング言語といった本明細書に説明する宣言型プログラミング言語に従う制約ベースの型付きモデルとの比較を例示するために、各モデルの型宣言のための例示的コードを以下で比較する。
【００８１】
先ず、名目型付き実行モデルに関して、以下の例示的Ｃ#コードを示す。
【００８２】
2012504826.tif 000022
【００８３】
この宣言に対して、固定の型−値関係が存在し、その関係においては、ＡおよびＢの値は、たとえそれらのフィールドの値、すなわちＢａｒおよびＦｏｏが同一であっても、比較にならないとみなされる。対照的に、制約ベースのモデルに関して、以下の例示的Ｄコード（以下でより詳細に論じる）は、オブジェクトがいくつかの型にどのように適合できるかを例示している。
【００８４】
2012504826.tif 000023
【００８５】
この宣言に対して、型−値関係は、型Ａに適合しＢにも適合する、またその逆も同様の全ての値として、よりずっと柔軟性がある。さらに、制約ベースのモデルにおける型は、互いの上に層を成すことができ、例えば、様々なＲＤＢＭＳにわたるプログラミングに対して有用であり得る柔軟性を提供する。実際、制約ベースのモデルにおける型は、最初は宇宙にある全ての値を含むので、特定の値は、その値が型の宣言にコード化された制約を犯さない全ての型に一致する。従って、宣言「ｔｙｐｅ  Ｔ  ：  Ｔｅｘｔ  ｗｈｅｒｅ  ｖａｌｕｅ＜１２８」によって定義される型に一致する値のセットは、「Ｉｎｔｅｇｅｒ」の制約または「ｖａｌｕｅ＜１２８」の制約を犯さない「ａｌｌ  Ｖａｌｕｅｓ  ｉｎ  ｔｈｅ  ｕｎｉｖｅｒｓｅ（宇宙にある全ての値）」を含む。
【００８６】
このように、一実施形態において、ソースコードのプログラミング言語は、上述のように、Ｍプログラミング言語で実装されたような、制約ベースの型システムを含む完全な宣言型言語である。
【００８７】
別の実施形態において、本明細書に説明する方法はまた、順序非依存実行モデルまたは非順序化実行モデルを有するプログラミング言語を用いて動作可能である。上述の制約ベースの実行モデルと同様、そのような順序非依存実行モデルは、様々なＲＤＢＭＳにわたるプログラミングに対して有用であり得る柔軟性を提供する。
【００８８】
図１２〜１３において、例示のために、順序化実行モデルに従うデータストレージ抽象化を、順序非依存実行モデルに従うデータストレージ抽象化と比較する。例えば、図１２のデータストレージ抽象化１２００は順序化実行モデルに従って作成されたリストＦｏｏを表し、一方、図１３のデータ抽象化１２１０は、順序非依存実行モデルにより作成された同様のリストＦｏｏを表す。
【００８９】
図示したように、データストレージ抽象化１２００および１２１０の各々には、３つのＢａｒ値（すなわち、“１”、“２”、および“３”）のセットを含む。しかし、データストレージ抽象化１２００は、これらのＢａｒ値を特定の順序で入力／リスト化することを要求し、一方、データストレージ抽象化１２１０は、そのような要求をしない。代わりに、データストレージ抽象化１２１０は単にＩＤを各ＢＡＲ値に割り当て、これらのＢａｒ値が入力／リスト化された順序は、ターゲットとするリポジトリには見えない。従って、例えば、データストレージ抽象化１２１０は、以下の順序非依存のコードから生じたかもしれない。
【００９０】
2012504826.tif 000024
【００９１】
しかし、データストレージ抽象化１２１０はまた、以下のコードから生じたのかもしれない。
【００９２】
2012504826.tif 000025
【００９３】
および上記２つのコードの各々は以下のコードと関数的に同等である。
【００９４】
2012504826.tif 000026
【００９５】
上述の制約ベースの型付き実行モデルおよび非順序化実行モデルと互換性のある例示的宣言型言語は、本明細書で時々便宜上「Ｍ」と称しているＭプログラミング言語であり、これは本発明の出願人が開発したものである。しかし、当然のことながら、Ｍに加えて、他の同様の宣言型プログラミング言語を使用してもよく、本発明のユーティリティは如何なる単一のプログラミング言語にも限定されるものではない。ここでは、上述の有向グラフ構造の任意の１つまたは複数の実施形態が適合する。これに関して、Ｍに関するいくつかの追加のコンテキストを以下に与える。
【００９６】
上述のように、Ｍはデータとともに動作する宣言型言語である。Ｍにより、ユーザは、オーサリング可能および読取り可能な便利なテキスト構文を使用して、自らのデータをどのように構造化し、クエリしたいかを決定する。一非限定的態様において、Ｍのプログラムには、正式にはコンパイル単位として知られている１つまたは複数のソースファイルを含み、そのソースファイルは、順序化された一連のＵｎｉｃｏｄｅ文字である。ソースファイルは一般的に、ファイルシステム内のファイルに一対一で一致するが、この一致は必要ではない。最高の移植性のために、ファイルシステム内のファイルをＵＴＦ−８エンコーディングでエンコードすることを推奨する。
【００９７】
概念的に言えば、Ｍのプログラムを４つのステップを使用してコンパイルする。すなわち、１）Ｕｎｉｃｏｄｅ入力文字のストリームをトークンのストリームに変換する字句解析（字句解析は前処理指令を評価および実行する）、２）トークンのストリームを抽象構文ツリーに変換する構文解析、３）全てのシンボルを抽象構文ツリーに解析し、その構造を型チェックし、意味グラフを生成する意味解析、４）なんらかのターゲットとするランタイムのために意味グラフから実行可能命令を生成するコード生成（例えば、ＳＱＬ、画像生成）である。さらなるツールが画像をリンクし、その画像をランタイムにロードすることができる。
【００９８】
宣言型言語として、Ｍは、データをどのように格納するか、またはデータにどのようにアクセスするかを命令せず、特定の実装技術を要求することもない（ＸＡＭＬといったドメイン固有言語とは対照的に）。それどころか、Ｍは、ユーザが、自らのデータから何が欲しいかを、その要望が所与の技術またはプラットフォームに対してどのように合致するかを指定する必要なく書き出すことができるよう設計された。すなわち、実装により、Ｍの構造を所与の環境内でどのように表し、どのように実行するかを制御するための宣言型または命令型の豊かなサポートを提供することを、Ｍが妨げることは全くなく、Ｍにより豊かな開発の柔軟性が可能となる。
【００９９】
Ｍは、３つの基本概念、すなわち、値、型、およびエクステントに基づく。これら３つの概念は、以下のように定義することができる。すなわち、１）値は、Ｍ言語の規則に適合するデータである、２）型は、値のセットを記述する、および３）エクステントは値に動的ストレージを提供する。
【０１００】
一般に、Ｍはデータの型付けをデータのストレージ／エクステントから分離する。所与の型を使用して複数のエクステントからデータを記述し、また計算の結果を記述する。これによりユーザは、先ず型を書き出すことを始め、後に対応する値をどこに置くか、またはどこで計算するかを決めることができる。
【０１０１】
値をどこに置くかを決定することについて、Ｍ言語は、実装が宣言されたエクステントをＲＤＢＭＳといった外部ストアにどのようにマップするかを指定しない。しかし、Ｍはそのような実装を可能とするよう設計され、リレーショナルモデルと互換性がある。
【０１０２】
データ管理に関して、Ｍはエクステントの概念を変更する構造を有しない関数型言語であるが、しかし、Ｍはエクステントのコンテンツが（Ｍに対して）外部の要因を介して、および任意で変更できることを予測しており、Ｍは更新データに宣言型構造を与えるよう修正されることが可能である。
【０１０３】
認証または割り当てのために値を分類する方法を書き出すことが、しばしば望ましい。Ｍにおいて、型を使用して値を分類し、Ｍの型は、受け入れ可能な値または適合する値の集合を記述する。さらに、Ｍの型を使用して、どの値が特定のコンテキスト（例えば、オペランド、ストレージ位置）に現れることができるかを制約する。
【０１０４】
明らかな例外は少々あるが、Ｍにより型を集合として使用することが可能となる。例えば、「ｉｎ」演算子を使用して、値が、例えば以下のような所与の型に適合するかどうかをテストすることができる。
【０１０５】
2012504826.tif 000027
【０１０６】
組込みの型の名前がＭ言語で直接利用可能であることには、留意すべきである。しかし、型の新しい名前を、型宣言を使用して導入してもよい。例えば、以下の型宣言は、「Ｔｅｘｔ」の簡単な型に型名「Ｍｙ  Ｔｅｘｔ」を同義語として導入する。
【０１０７】
2012504826.tif 000028
【０１０８】
ここで利用可能となるこの型名を用いて、以下のコードを書くことができる。
【０１０９】
2012504826.tif 000029
【０１１０】
既存の型に対してカスタム名を導入することは有用である一方、以下のように、基礎となる型にプレディケートを適用することは、さらに有用である。
【０１１１】
2012504826.tif 000030
【０１１２】
本例において、可能な「Ｔｅｘｔ」値の母集団は、値が７文字より少ない「Ｔｅｘｔ」値に制約されている。従って、以下のステートメントがこの型定義に当てはまる。
【０１１３】
2012504826.tif 000031
【０１１４】
型宣言が以下を作成する。
【０１１５】
2012504826.tif 000032
【０１１６】
しかし、本例において、この宣言は以下に等しい。
【０１１７】
2012504826.tif 000033
【０１１８】
Ｍの宣言またはＭの式が参照できるように、型の名前が存在することに留意されたい。任意数の名前を同一の型（例えば、Ｔｅｘｔ  ｗｈｅｒｅ  ｖａｌｕｅ．Ｃｏｕｎｔ＜７）に割り当てることができ、所与の値は、それらの全てに適合するか、またはそれらのどれにも適合しないかのどちらかである。例えば、次の例について考察する。
【０１１９】
2012504826.tif 000034
【０１２０】
これらの２つの型定義を与えると、以下の式、
【０１２１】
2012504826.tif 000035
【０１２２】
は両方とも真と評価される。以下の第３の型を導入する場合、
【０１２３】
2012504826.tif 000036
【０１２４】
以下を述べることができる。
【０１２５】
2012504826.tif 000037
【０１２６】
Ｍの一般原則は、所与の値が任意数の型に適合できることである。これは、多くのオブジェクトベースのシステムが動作する方法からの脱却であり、オブジェクトベースのシステムでは、値は初期化時に特定の型にバインドされ、その型が定義されたときに指定されたサブの型の限定されたセットの一部である。
【０１２７】
ここに論じる別の型に関する演算は、型帰属演算子（：）である。型帰属演算子は、所与の値が特定の型に適合することを主張する。
【０１２８】
一般に、式中に値が見られる場合、Ｍは、適用されている演算子／関数に対する宣言された結果の型に基づく、その値の予測される型の概念をいくつか有する。例えば、論理
「ａｎｄ」演算子（＆＆）の結果は、型「Ｌｏｇｉｃａｌ」に一致するよう宣言される。
【０１２９】
追加の制約を所与の値に適用すること、つまり一般的には、異なる要件を有する別のコンテキストにおいてその値を使用することは、時折有用である（または必要でさえある）。例えば、以下の型定義について考察する。
【０１３０】
2012504826.tif 000038
【０１３１】
オペランドとして型「ＳｕｐｅｒＰｏｓｉｔｉｖｅ」の値を受け入れると宣言する「ＣａｌｃＩｔ」と名づけられた関数があると仮定すると、Ｍにおいて、以下のような式、
【０１３２】
2012504826.tif 000039
【０１３３】
を許可し、以下のような式、
【０１３４】
2012504826.tif 000040
【０１３５】
を禁ずることが望ましい。
【０１３６】
実際、Ｍはこれら４つの例に対して望むことを正確に行う。これは、これらの式が、定数にかかる組み込みの演算子に関してそれらのオペランドを表すからである。式に対するＭのソーステキストにほとんど犠牲を払うことなく遭遇した瞬間に、式の有効性を決定するために必要とされる情報はすべて直ちに利用可能となる。
【０１３７】
しかし、式がデータの動的ソースおよび／またはユーザ定義の関数を利用する場合、型帰属演算子を使用して、値が所与の型に適合することを主張する。
【０１３８】
型帰属演算子が値を用いてどのように作用するかを理解するために、型「Ｔｅｘｔ」のオペランドを受け入れ、そのオペランド内の母音数を示す型「Ｎｕｍｂｅｒ」の値を返すと宣言する、第２の関数「ＧｅｔＶｏｗｅｌＣｏｕｎｔ」を仮定する。
【０１３９】
「ＧｅｔＶｏｗｅｌＣｏｕｎｔ」の宣言に基づくと、その結果が５より多くなるかどうかは分からないので、従って以下の式は正当なＭの式ではない。
【０１４０】
2012504826.tif 000041
【０１４１】
「ＧｅｔＶｏｗｅｌＣｏｕｎｔ」の宣言された結果の型（Ｎｕｍｂｅｒ）が、「ＣａｌｃＩｔ」の宣言されたオペランドの型（ＳｕｐｅｒＰｏｓｉｔｉｖｅ）に適合しない値を含むので、この式は正当ではない。この式は誤ってかかれたと推測される。
【０１４２】
しかし、この式を、型帰属演算子を使用して、以下の（正当な）式に書き換えることができる。
【０１４３】
2012504826.tif 000042
【０１４４】
この式により、「ＧｅｔＶｏｗｅｌＣｏｕｎｔ」関数を充分に理解しており、型「ＳｕｐｅｒＰｏｓｉｔｉｖｅ」に適合する値が得られるであろう事を知っているということを、Ｍに知らせる。要するに、プログラマは、Ｍがしていることを自分は知っているということを、Ｍに告げている。
【０１４５】
しかし、プログラマがそれを知らない場合、例えば、プログラマが「ＧｅｔＶｏｗｅｌＣｏｕｎｔ」関数がどう作用するか見誤った場合、特定の評価の結果、負の数となり得る。「ＣａｌｃＩｔ」関数を、「ＳｕｐｅｒＰｏｓｉｔｉｖｅ」に適合する値のみを受け入れると宣言したので、システムはそれに渡す全ての値が５より大きいことを保証するであろう。この制約が決して違反されないことを保証するために、システムは、評価された時に失敗する可能性のある動的な制約テストを投入してもよい。この失敗は、Ｍのソーステキストを最初に処理する際には起こらないであろうが（Ｃａｌｔ（−１）であった場合のように）、式が実際に評価される際に起こるであろう。
【０１４６】
これに関して、Ｍの実装は一般的に、Ｍのドキュメント内の第１の式を評価する前に、如何なる制約違反も報告するよう試みる。これを静的強制と呼び、実装はまるで構文エラーのようにこれを示す。しかし、いくつかの制約のみを、ライブデータに対して強制することができ、従ってそれらの制約は動的強制を要求する。
【０１４７】
この点において、Ｍにより、ユーザが自らの意図を書き出すことが容易になり、Ｍの実装に「それを動作させる」ために負担をかけることになる。任意で、特定のＭのドキュメントを多様な環境で使用できるように、動的制約違反の性能コストおよび動作コストを軽減するために正確性に対する動的強制に依存するＭのドキュメントを拒絶するよう、充分に機能を備えたＭの実装を構成可能である。
【０１４８】
さらなる背景の観点として、型コンストラクタであるＭを、集合型を指定するために定義することができる。集合型コンストラクタは、集合に含むことができる型および要素数を制限する。すべての集合型は固有の型「Ｃｏｌｌｅｃｔｉｏｎ」にかかる制限であり、例えば、全ての集合値は以下の式に適合する。
【０１４９】
2012504826.tif 000043
【０１５０】
直前の例は、集合型が単一の型と重ならないことを明示している。集合型および単一の型の両方に適合する値は存在しない。
【０１５１】
集合型コンストラクタは要素の型および受け入れ可能な要素数の両方を指定する。要素数は一般的に、３つの演算子のうちの１つを使用して指定される。
【０１５２】
2012504826.tif 000044
【０１５３】
集合型コンストラクタは、Ｋｌｅｅｎｅ演算子を使用するか、または固有の型Ｃｏｌｌｅｃｔｉｏｎにかかる制約として略さずに書くことができる。つまり、以下の型宣言は集合値の同一のセットを記述する。
【０１５４】
2012504826.tif 000045
【０１５５】
これらの型は、これらの略していない定義として値の同一のセットを記述する。
【０１５６】
2012504826.tif 000046
【０１５７】
型を宣言するためにどの形式を使用するかに関わりなく、以下の式を述べることができる。
【０１５８】
2012504826.tif 000047
【０１５９】
集合型コンストラクタは、「ｗｈｅｒｅ」演算子を用いて作成し、以下の型チェックを成功させる。
【０１６０】
2012504826.tif 000048
【０１６１】
内側の「ｗｈｅｒｅ」演算子を集合の要素に適用し、外側の「ｗｈｅｒｅ」演算子を集合それ自体に適用することに留意されたい。
【０１６２】
集合型コンストラクタを使用してどの種類の集合が所与のコンテキストに有効かを指定することができると、同じ事を、エンティティ型を使用してエンティティに対して行うことができる。
【０１６３】
これに関して、エンティティ型はエンティティ値のセットに対して予期されるメンバを宣言する。エンティティ型のメンバを、フィールドとして、または計算値としてのどちらかで宣言することができる。フィールドの値は格納され、計算値の値は算定される。エンティティ型は、Ｍの標準ライブラリで定義されるＥｎｔｉｔｙの型にかかる制限である。
【０１６４】
以下は簡単なエンティティ型である。
【０１６５】
2012504826.tif 000049
【０１６６】
型「ＭｙＥｎｔｉｔｙ」は如何なるフィールドも宣言しない。Ｍにおいて、型に適合するエンティティ値が、その名前が型に宣言されていないフィールドを含むことができるという点において、エンティティ型はオープンである。従って、以下の型テスト、
【０１６７】
2012504826.tif 000050
【０１６８】
は、「ＭｙＥｎｔｉｔｙ」型が、ＸおよびＹと名づけられたフィールドについて何も言っていないので、真と評価されるであろう。
【０１６９】
エンティティ型は１つまたは複数のフィールド宣言を含むことができる。フィールド宣言は、最小限でも、予期されるフィールドの名前を述べる。例えば、
【０１７０】
2012504826.tif 000051
【０１７１】
である。
【０１７２】
この型定義は、少なくともＸおよびＹと名づけられたフィールドをそのフィールドの値に関わりなく含む、エンティティのセットを記述し、それは、以下の型テストが真と評価されることを意味する。
【０１７３】
2012504826.tif 000052
【０１７４】
直前の例は、「Ｐｏｉｎｔ」型がＸおよびＹのフィールドの値を制約しないことを示す。すなわち、如何なる値も可能である。ＸおよびＹの値を数値に制約する新しい型を以下のように示す。
【０１７５】
2012504826.tif 000053
【０１７６】
型帰属構文を使用して、ＸおよびＹのフィールドの値が型「Ｎｕｍｂｅｒ」に適合すべきであることを主張することに留意されたい。適所でこれを用いて、以下の式が真と評価される。
【０１７７】
2012504826.tif 000054
【０１７８】
簡単な型についての論述にみられたように、型の名前が存在し、Ｍの宣言およびＭの式はそれを参照することができる。それゆえ、ＮｕｍｅｒｉｃＰｏｉｎｔおよびＰｏｉｎｔの定義が独立しているにもかかわらず、以下の型テストは両方とも成功する。
【０１７９】
2012504826.tif 000055
【０１８０】
Ｍにおけるフィールドは、値を保持するストレージの名づけられた単位である。Ｍにより開発者は、フィールドの値をエンティティイニシャライザの一部として初期化することができる。しかし、Ｍは、フィールドの値をいったん初期化すると、その値を変更するためのメカニズムを何ら指定しない。Ｍにおいては、フィールド値への如何なる変更も、Ｍの範囲の外側で起こると仮定している。
【０１８１】
フィールド宣言は、そのフィールドに対するデフォルト値が存在することを示すことができる。デフォルト値を有するフィールド宣言は、適合するエンティティが指定された対応するフィールドを有することを要求しない（そのようなフィールド宣言は時に任意のフィールドと呼ばれる）。例えば、以下の型定義に関して、
【０１８２】
2012504826.tif 000056
【０１８３】
Ｚのフィールドはデフォルト値を有するので、以下の型テストは成功する。
【０１８４】
2012504826.tif 000057
【０１８５】
さらに、型帰属演算子を以下のように値に適用する場合、
【０１８６】
2012504826.tif 000058
【０１８７】
次いで、Ｚのフィールドに以下のようにアクセスすることができ、
【０１８８】
2012504826.tif 000059
【０１８９】
この場合、この式により値−１が得られる。
【０１９０】
別の非限定的態様において、フィールド宣言が対応するデフォルト値を有しない場合、適合するエンティティは、そのフィールドに対する値を指定しなければならない。デフォルト値は一般的に、「Ｐｏｉｎｔ３ｄ」のＺのフィールドに対して示された明示的な構文を使用して書き出される。フィールドの型が、ｎｕｌｌ許容型かまたは０〜多の集合のいずれかであれば、任意としてのｎｕｌｌの宣言フィールドおよび集合としての｛｝に対して暗示的なデフォルト値が存在する。
【０１９１】
例えば、以下の型について考察する。
【０１９２】
2012504826.tif 000060
【０１９３】
次いで、再度、以下の型テストは成功するであろう。
【０１９４】
2012504826.tif 000061
【０１９５】
および、「ＰｏｉｎｔＮＤ」がその値に帰属するものとみなすことにより、このようなデフォルトが得られる。
【０１９６】
2012504826.tif 000062
【０１９７】
モデルとなる任意のフィールドへ、０〜１の集合を使用すること、対、明示的なデフォルト値を使用することの選択は、一般的にはスタイルの一つとなる。
【０１９８】
計算値は、その値を格納するのではなく計算する、名づけられた式である。そのような計算値を宣言する型の例は、以下である。
【０１９９】
2012504826.tif 000063
【０２００】
セミコロンで終わるフィールド宣言とは異なり、計算値宣言は中括弧で囲われた式で終わることに留意されたい。
【０２０１】
フィールド宣言のように、計算値宣言は、本例のように型帰属を省略する。
【０２０２】
2012504826.tif 000064
【０２０３】
別の非限定的態様においては、如何なる型も計算値に明示的に帰属するものとみなされない場合、Ｍは、基礎となる式の宣言された結果の型に自動的に基づいて、型を推測することができる。本例では、式で使用される論理ａｎｄ演算子は、「Ｌｏｇｉｃａｌ」を返すよう宣言されたので、「ＩｎＭａｇｉｃＱｕａｄｒａｎｔ」の計算値はまた「Ｌｏｇｉｃａｌ」値を得ることに帰属するものとみなされる。
【０２０４】
上述で定義および使用した２つの計算値は、それらの結果を計算するために、エンティティ値それ自体以外に何ら追加の情報を必要としなかった。計算値は、式中で計算値を使用する場合その実際の値を指定しなければならない名づけられたパラメータのリストを、任意で宣言してもよい。以下は、パラメータを必要とする計算値の例である。
【０２０５】
2012504826.tif 000065
【０２０６】
式中でこの計算値を使用するために、以下のように、２つのパラメータに値を与える。
【０２０７】
2012504826.tif 000066
【０２０８】
「ＷｉｔｈｉｎＢｏｕｎｄｓ」の値を計算する場合、Ｍは値５０をシンボルの範囲にバインドし、それにより「ＷｉｔｈｉｎＢｏｕｎｄｓ」の計算値は偽と評価される。
【０２０９】
Ｍについては、フィールドの計算値およびデフォルト値は両方とも、型定義の一部であり、型に適合する値の一部ではないことに留意されたい。例えば、これら３つの型定義について考察する。
【０２１０】
2012504826.tif 000067
【０２１１】
ＲｉｃｈＰｏｉｎｔおよびＷｅｉｒｄＰｏｉｎｔは２つの必要なフィールド（ＸおよびＹ）を有するだけなので、以下を述べることができる。
【０２１２】
2012504826.tif 000068
【０２１３】
しかし、「ＩｓＨｉｇｈ」の計算値は、これら２つの型のうち１つがエンティティ値に帰属するとみなされる場合にのみ利用可能である。
【０２１４】
2012504826.tif 000069
【０２１５】
計算値は、完全に型の一部であり、値ではないので、帰属が以下のようにつながる場合、
【０２１６】
2012504826.tif 000070
【０２１７】
最も外側の帰属が、どの関数を呼び出すかを決定する。
【０２１８】
デフォルト値がどのように作用するかに関して、同様の原理が登場する。デフォルト値は型の一部であり、エンティティ値ではないことに、再度留意されたい。従って、以下の式を書く場合、
【０２１９】
2012504826.tif 000071
【０２２０】
基礎となるエンティティ値は依然２つのフィールド値（それぞれ、Ｘに対して１、およびＹに対して２）を含むだけである。これに関して、デフォルト値が計算値と異なる場合、帰属がつながる。例えば、以下の式を考察する。
【０２２１】
2012504826.tif 000072
【０２２２】
「ＲｉｃｈＰｏｉｎｔ」の帰属が先ず適用されるので、結果として得られるエンティティは、−１の値を有するＺと名づけられたフィールドを有する。しかし、その値の割り当てられたストレージは存在しない。すなわち、それはその値の型の解釈の一部である。
従って、「ＷｅｉｒｄＰｏｉｎｔ」の帰属が適用されると、それは、Ｚと名づけられたフィールドを有さない最初の帰属の結果に適用され、その結果、値を使用してＺに対する値を指定する。従って、「ＷｅｉｒｄＰｏｉｎｔ」によって指定されたデフォルト値は、必要ではない。
【０２２３】
全ての型と同様に、制約を「ｗｈｅｒｅ」演算子を使用するエンティティ型に適用してもよい。以下のＭの型定義を考察する。
【０２２４】
2012504826.tif 000073
【０２２５】
本例において、型「ＨｉｇｈＰｏｉｎｔ」に適合する全ての値は、Ｙの値より小さいＸの値を有するよう保証される。それは、以下の式を意味し、
【０２２６】
2012504826.tif 000074
【０２２７】
両方とも真と評価される。
【０２２８】
さらに、以下の型定義に関して、
【０２２９】
2012504826.tif 000075
【０２３０】
第３の型「ＶｉｓｕａｌＰｏｉｎｔ」は、少なくとも数値フィールドＸ、Ｙ、Ｏｐａｃｉｔｙ、およびＤｏｔＳｉｚｅを有するエンティティ値のセットに名前をつける。
【０２３１】
メンバ宣言を、作成できるより小さなものに分解することは共通の願いであるので、Ｍはまた、明示的な構文の支援を分解に与える。例えば、「ＶｉｓｕａｌＰｏｉｎｔ」の型定義はその構文を使用して書き換えられる。
【０２３２】
2012504826.tif 000076
【０２３３】
明らかにするために、これは、制約の式を使用した上記略していない定義に対して、簡略化したものである。さらに、この簡略化した定義および略していない定義の両方とも、これよりさらに略していない以下の定義に等しい。
【０２３４】
2012504826.tif 000077
【０２３５】
再度、型の名前は、まさに型に言及する方法である。値それ自体は、それらを記述するために使用した型名の記録を有さない。
【０２３６】
Ｍはまた、いくつかの特徴をもつＬＩＮＱ  ｑｕｅｒｙ  ｃｏｍｐｒｅｈｅｎｓｉｏｎを拡張して、簡単なオーサリングをより簡潔にすることができる。キーワードである「ｗｈｅｒｅ」および「ｓｅｌｅｃｔ」は、２項中置演算子として利用可能である。また、インデクサを強く型付けされた集合に自動的に加える。これらの特徴により、共通のクエリを以下に例示するようにより簡潔にオーサリングすることができる。
【０２３７】
中置演算子としての「ｗｈｅｒｅ」の例として、以下のクエリが「Ｐｅｏｐｌｅ」と定義された集合から３０歳未満の人々を抽出する。
【０２３８】
2012504826.tif 000078
【０２３９】
同等のクエリを以下のように書くことができる。
【０２４０】
2012504826.tif 000079
【０２４１】
「ｗｈｅｒｅ」演算子は、左側に集合を、右側にブール式を取る。「ｗｈｅｒｅ」演算子は、キーワード識別子の値を、集合の各メンバにバインドされたブール式の範囲に取り入れる。結果の集合には、その式が真であるメンバを含む。従って、式
【０２４２】
2012504826.tif 000080
【０２４３】
は、以下に等しい。
【０２４４】
2012504826.tif 000081
【０２４５】
Ｍのコンパイラが、強く型付けされた要素を有する集合にインデクサのメンバを加える。例えば、集合「Ｐｅｏｐｌｅ」に対し、コンパイラは、「Ｆｉｒｓｔ（Ｔｅｘｔ）」、「Ｌａｓｔ（Ｔｅｘｔ）」および「Ａｇｅ（Ｎｕｍｂｅｒ）」に対するインデクサを加えるかもしれない。
【０２４６】
従って、ステートメント、
【０２４７】
2012504826.tif 000082
【０２４８】
は、以下に等しい。
【０２４９】
2012504826.tif 000083
【０２５０】
「ｓｅｌｅｃｔ」もまた、中置演算子として利用可能である。以下の簡単なクエリに関して、
【０２５１】
2012504826.tif 000084
【０２５２】
「ｓｅｌｅｃｔ」の式は、集合の各メンバに渡って算定され、結果を返す。中置の「ｓｅｌｅｃｔ」を使用して、クエリを同等に以下のように書くことができる。
【０２５３】
2012504826.tif 000085
【０２５４】
「ｓｅｌｅｃｔ」演算子は、左側に集合を、右側に任意の式を取る。「ｗｈｅｒｅ」を用いる場合のように、「ｓｅｌｅｃｔ」は、集合内の各要素に渡って範囲を定めたキーワード識別子の値を取り入れる。「ｓｅｌｅｃｔ」演算子は、式を集合内の各要素上にマッピングし、結果を返す。別の例として、ステートメント、
【０２５５】
2012504826.tif 000086
【０２５６】
は、以下に等しい。
【０２５７】
2012504826.tif 000087
【０２５８】
「ｓｅｌｅｃｔ」演算子は普通、単一のフィールドを抽出するために使用する
【０２５９】
2012504826.tif 000088
【０２６０】
コンパイラは、単一のフィールドを「Ｐｅｏｐｌｅ．Ｆｉｒｓｔ」および「Ｐｅｏｐｌｅ．Ｌａｓｔ」として直接抽出できるように、集合にアクセサを加える。
【０２６１】
正当なＭの文書を書くために、全てのソーステキストがモジュール定義のコンテキストに現れる。モジュールは、定義される任意の型名に対して、最高レベルの名前空間を定義する。モジュールはまた、実際の値および計算値を格納するエクステントを定義する範囲を定義する。
【０２６２】
以下はモジュール定義の簡単な例である。
【０２６３】
2012504826.tif 000089
【０２６４】
2012504826.tif 000090
【０２６５】
本例では、モジュールは「Ｇｅｏｍｅｔｒｙ．Ｐｏｉｎｔ」と名づけられた１つの型を定義する。この型は、ポイント値がどのように見えるかを記述するが、それらの値を格納できる如何なる位置も定義しない。
【０２６６】
本例にはまた、２つのモジュールが範囲を定めたフィールド（ＰｏｉｎｔｓおよびＯｒｉｇｉｎ）を含む。モジュールが範囲を定めたフィールドの宣言は、エンティティ型で使用された宣言に構文で一致する。しかし、エンティティ型で宣言されたフィールドは、いったんエクステントが決定されると、ストレージとしての可能性に単に名前をつけるだけであるが、対照的に、モジュールの範囲で宣言されたフィールドは、モジュールをロードおよび解釈するために実装によりマッピングしなければならない実際のストレージに名前をつける。
【０２６７】
さらに、モジュールは、参照される宣言を含んでいるモジュールに名前をつけるためのインポート指示を使用することによって、他のモジュール内の宣言を参照することができる。宣言が他のモジュールによって参照されるように、その宣言を、エクスポート指示を使用して明示的にエクスポートする。
【０２６８】
たとえば、以下のモジュールを考察する。
【０２６９】
2012504826.tif 000091
【０２７０】
「ＭｙＴｙｐｅ１」および「ＭｙＥｘｔｅｎｔ１」のみが他のモジュールに見えており、そのため以下の「ＨｅｒＭｏｄｕｌｅ」の定義が正当となることに留意されたい。
【０２７１】
2012504826.tif 000092
【０２７２】
本例が示すように、モジュールは循環する依存性を有してもよい。
【０２７３】
Ｍ言語の型を２つの主なカテゴリ、すなわち、固有型および派生型に分ける。固有型は、Ｍ言語の構造を使用して定義することはできないが、Ｍ言語の仕様において完全に定義する型である。固有型は、その仕様の一部として、そのスーパー型としてせいぜい１つの固有型に名前をつければよい。値は、まさに１つの固有型のインスタンスであり、その１つの固有型およびそのスーパー型の全ての仕様に適合する。
【０２７４】
派生型は、言語内に与えられた型コンストラクタを使用して、Ｍのソーステキスト内にその定義を構築する型である。派生型を別の型にかかる制約として定義し、それにより明示的なサブの型付け関係を生み出す。値は、単に派生型の制約を満足させるというだけで、任意数の派生型に適合する。値と派生型との間には、推測的な関係は全くない。それどころか、派生型の制約に適合する所与の値を、意のままにその型として解釈してよい。
【０２７５】
Ｍは型を定義する際、幅広い選択の範囲を与える。集合を返す任意の式を、型として使用することができる。エンティティおよび集合に対する型プレディケートは、式であり、この形式に適合する。型宣言は明示的にそのメンバを列挙するか、または他の型から構成してもよい。
【０２７６】
Ｍのような構造的型付き言語と名目型付き言語との間に、別の違いがある。Ｍにおける型は値のセットに対する仕様である。２つの型は、まさに同一の値の集合が型の名前に関わりなく両方に適合する場合、同一である。使用するために型に名前をつける必要はない。型の式は、型参照が必要であれば許可される。Ｍにおける型は、単に集合を返す式である。
【０２７７】
型は、型プレディケートを満足させる全ての値の集合とみなされる。そのため、集合への如何なる演算も型に適用することができ、型は、他の任意の集合値のように式を用いて操作することができる。
【０２７８】
Ｍは、出現するために、値に２つの一次的な手段、すなわち計算値および格納値（ａ．ｋ．ａ．フィールド）を与える。計算値および格納値は、モジュールの宣言およびエンティティの宣言の両方を用いて発生し、それらのコンテナにより範囲を定められる。計算値は一般にＭのソーステキストの一部として定義された式を評価することから派生する。対照的に、フィールドが値を格納し、そのフィールドのコンテンツが時間とともに変化することができる。
【０２７９】
＜例示的ネットワーク環境および例示的分散環境＞
本明細書に説明した宣言的プログラミングモデルのための拡張可能な構文の様々な実施形態を、コンピュータネットワークの一部として、または分散コンピューティング環境において配置でき、かつ任意の種類のデータストアに接続できる任意のコンピュータ、または他のクライアント装置もしくはサーバ装置に関連して実装できることは、当業者には理解できよう。これに関して、本明細書に説明した様々な実施形態を、任意数のメモリまたは任意数のストレージユニット、ならびに任意数のアプリケーションおよび任意数のストレージユニットに渡って発生する任意数のプロセスを有する、任意のコンピュータシステムまたは任意のコンピュータ環境において実装することができる。これには、ネットワーク環境または分散コンピューティング環境に配置され、リモートのストレージまたはローカルのストレージを有する、サーバコンピュータおよびクライアントコンピュータを有する環境を含むが、それに限らない。
【０２８０】
分散コンピューティングは、コンピューティング装置およびコンピューティングシステム間の通信のやりとりにより、コンピュータリソースおよびコンピュータサービスの共有を提供する。これらのリソースおよびサービスには、情報の交換、ファイルといったオブジェクトのためのキャッシュストレージおよびディスクストレージを含む。これらのリソースおよびサービスにはまた、ロードバランシング、リソースの拡張、処理の特化などのための複数の処理ユニットに渡る処理能力の共有を含む。分散コンピューティングは、ネットワーク接続を利用し、企業全体に利益をもたらすようにクライアントがその集約的能力を活用できるようにする。これに関して、様々な装置が、本主題開示の様々な実施形態のいずれかの１つまたは複数の態様を実施するよう協働する、アプリケーション、オブジェクト、またはリソースを有してもよい。
【０２８１】
図１４は、例示的ネットワークコンピューティング環境または例示的分散コンピューティング環境の概略図を提供する。分散コンピューティング環境には、コンピューティングオブジェクト１４１０、１４１２など、およびコンピューティングオブジェクトまたはコンピューティング装置１４２０、１４２２、１４２４、１４２６、１４２８などを含み、それらは、アプリケーション１４３０、１４３２、１４３４、１４３６、１４３８によって表されるように、プログラム、方法、データストア、プログラム可能な論理などを含んでもよい。当然のことながら、オブジェクト１４１０、１４１２など、およびコンピューティングオブジェクトまたはコンピューティング装置１４２０、１４２２、１４２４、１４２６、１４２８などは、ＰＤＡ、オーディオ／ビデオ装置、携帯電話、ＭＰ３プレイヤ、パーソナルコンピュータ、ラップトップなどといった、異なる装置を備えてもよい。
【０２８２】
各オブジェクト１４１０、１４１２など、およびコンピューティングオブジェクトまたはコンピューティング装置１４２０、１４２２、１４２４、１４２６、１４２８などは、１つまたは複数の他のオブジェクト１４１０、１４１２など、およびコンピューティングオブジェクトまたはコンピューティング装置１４２０、１４２２、１４２４、１４２６、１４２８などと、通信ネットワーク１４４０を介して、直接または間接のいずれかで通信することができる。図１４では単一の要素として示しているが、図示していないものの、ネットワーク１４４０は、図１４のシステムにサービスを提供する他のコンピューティングオブジェクトおよびコンピューティング装置を備えてもよく、かつ／または複数の相互接続のネットワークを表してもよい。各オブジェクト１４１０、１４１２など、または１４２０、１４２２、１４２４、１４２６、１４２８などは、アプリケーション１４３０、１４３２、１４３４、１４３６、１４３８といったアプリケーションを含むこともでき、それらのアプリケーションは、互いに通信するか、処理するのに適した、または本主題開示の様々な実施形態に従って提供するデータスクリプト言語のための拡張可能な構文の実装に適した、ＡＰＩ、または他のオブジェクト、ソフトウェア、ファームウェアおよび／またはハードウェアを利用してもよい。
【０２８３】
分散コンピューティング環境をサポートする、様々なシステム、コンポーネント、およびネットワーク構成が存在する。例えば、コンピューティングシステムを、有線のシステムまたは無線のシステムによって、ローカルネットワークまたは広域分散ネットワークによって互いに接続することができる。現在、多くのネットワークがインターネットに接続されており、インターネットは、広域分散コンピューティングにインフラストラクチャを提供し、多くの異なるネットワークを包含するが、様々な実施形態において説明したように、データスクリプト言語のための拡張可能な構文に付随する例示的な通信に、任意のネットワークインフラストラクチャを使用することができる。
【０２８４】
従って、クライアント／サーバ、ピア・ツー・ピア、または混成アーキテクチャといった、ネットワークトポロジおよびネットワークインフラストラクチャのホストを利用することができる。「クライアント」は、関係のない別のクラスまたはグループのサービスを使用する、あるクラスまたはグループのメンバである。クライアントはプロセス、すなわちおおむね、別のプログラムまたはプロセスにより提供されるサービスを要求する命令またはタスクのセットであることができる。クライアントプロセスは、他のプログラムまたはサービス自体について、その動作の詳細を「知る」必要なく、要求したサービスを利用する。
【０２８５】
クライアント／サーバアーキテクチャ、とりわけネットワークシステムにおいて、クライアントはたいてい、別のコンピュータ、例えばサーバにより提供される共有ネットワークリソースにアクセスするコンピュータである。図１４の例示において、非限定的な例として、コンピュータ１４２０、１４２２、１４２４、１４２６、１４２８などをクライアントと考えることができ、かつコンピュータ１４１０、１４１２などをサーバと考えることができ、ここでは、サーバ１４１０、１４１２などが、クライアントコンピュータ１４２０、１４２２、１４２４、１４２６、１４２８などからのデータの受信、データの格納、データの処理、クライアントコンピュータ１４２０、１４２２、１４２４、１４２６、１４２８などへのデータの送信といった、データサービスを提供するが、状況に応じて、任意のコンピュータをクライアント、サーバ、またはその両方とみなすことができる。これらのコンピューティング装置のいずれも、データを処理する、データをエンコードする、データをクエリする、または、1つもしくは複数の実施形態に対して本明細書に説明したように拡張可能な構文に関わることのできるサービスもしくはタスクを要求することが可能である。
【０２８６】
サーバは一般的に、インターネットまたは無線ネットワークインフラストラクチャといった、リモートのネットワークまたはローカルのネットワーク上でアクセス可能なリモートコンピュータシステムである。クライアントプロセスは、第１のコンピュータシステムにおいてアクティブであり、サーバプロセスは、第２のコンピュータシステムにおいてアクティブであることができ、通信媒体上で互いに通信し、従って、分散機能を提供し、かつ複数のクライアントがサーバの情報収集能力を利用することを可能にする。データスクリプト言語のための拡張可能な構文に従って利用される任意のソフトウェアオブジェクトを、スタンドアロンで、または複数のコンピューティング装置もしくはコンピューティングオブジェクトに渡って分散して提供することができる。
【０２８７】
例えば、通信ネットワーク／バス１４４０がインターネットであるネットワーク環境において、サーバ１４１０、１４１２などは、クライント１４２０、１４２２、１４２４、１４２６、１４２８などがＨＴＴＰ（ｈｙｐｅｒｔｅｘｔ  ｔｒａｎｓｆｅｒ  ｐｒｏｔｏｃｏｌ）といったいくつかの既知のプロトコルのいずれかを介して通信する、Ｗｅｂサーバであることができる。サーバ１４１０、１４１２などは、分散コンピューティング環境の特徴であるように、クライント１４２０、１４２２、１４２４、１４２６、１４２８などとして機能してもよい。
【０２８８】
＜例示的コンピューティング装置＞
上述のように、有利なことには、本明細書に説明した技術を、例えば大量のデータを素早くクエリするというように、データ集約型アプリケーションを開発および実行することが望ましい任意の装置に適用することができる。従って、当然のことながら、ハンドヘルド、ポータブル、および他のコンピューティング装置、ならびに全ての種類のコンピューティングオブジェクトを、様々な実施形態に関連して使用する、すなわち、装置が高速および有効な結果を求めて大量のデータをスキャンまたは処理したいような場合に、それらを使用することを考慮する。従って、図１５においてこれから説明する以下の汎用リモートコンピュータは、コンピューティング装置の一例に過ぎない。
【０２８９】
必ずしも必要ではないが、実施形態を、装置またはオブジェクトのためのサービスの開発者が使用できるように、オペレーティングシステムを介して部分的に実装することができ、かつ／または本明細書に説明した様々な実施形態の１つまたは複数の関数の態様を実施するよう動作する、アプリケーションソフトウェア内に含むことができる。ソフトウェアを、クライアントワークステーション、サーバ、または他の装置といった、１つまたは複数のコンピュータにより実行されているプログラムモジュールといった、コンピュータ実行可能命令の一般的コンテキストで説明してもよい。コンピュータシステムは、データを通信するために使用できる様々な構成およびプロトコルを有しており、従って、如何なる特定の構成またはプロトコルに限るものとみなすべきではないことは、当業者には理解できよう。
【０２９０】
従って、図１５は、本明細書に説明した実施形態の１つまたは複数の態様を実装できる、適切なコンピューティングシステム環境１５００の例を示すが、上述を明確にすると、コンピューティングシステム環境１５００は、適切なコンピューティングシステム環境の一例にすぎず、使用または機能の範囲に何ら制限を示唆するよう意図するものではない。また、コンピューティング環境１５００を、例示的オペレーティング環境１５００に示したコンポーネントのいずれか１つまたは組み合わせに関して何らかの依存性または要件を有するものと解釈すべきでもない。
【０２９１】
図１５を参照すると、１つまたは複数の実施形態を実装するための例示的なリモート装置には、コンピュータ１５１０の形で汎用コンピューティング装置を含む。コンピュータ１５１０のコンポーネントには、処理ユニット１５２０、システムメモリ１５３０、およびシステムメモリを含む様々なシステムコンポーネントを処理ユニット１５２０に結合するシステムバス１５２２を含むことができるが、これに限らない。
【０２９２】
コンピュータ１５１０には一般的に、様々なコンピュータ可読媒体を含み、それらは、コンピュータ１５１０によりアクセス可能な任意の利用可能な媒体であることができる。システムメモリ１５３０には、ＲＯＭ（ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）および／またはＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）といった、揮発性および／または不揮発性メモリの形で、コンピュータストレージ媒体を含むことができる。限定ではなく例としてだが、メモリ１５３０にはまた、オペレーティングシステム、アプリケーションプログラム、他のプログラムモジュール、およびプログラムデータを含むことができる。
【０２９３】
ユーザは、入力装置１５４０を介してコンピュータ１５１０に命令および情報を入力することができる。モニタまたは他の種類の表示装置を、出力インタフェース１５５０といったインタフェースを介して、システムバス１５２２に接続することもできる。モニタに加えて、コンピュータにはまた、スピーカおよびプリンタといった、出力インタフェース１５５０を介して接続できる他の周辺出力装置を含むことができる。
【０２９４】
コンピュータ１５１０は、リモートコンピュータ１５７０といった１つまたは複数の他のリモートコンピュータへの論理接続を使用するネットワーク環境または分散環境において動作することができる。リモートコンピュータ１５７０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスもしくは他の共通ネットワークノード、または他の任意のリモート媒体消費装置もしくは他の任意のリモート媒体送信装置であることができ、かつコンピュータ１５１０に関して上述した要素のうち任意のものまたは全てを含むことができる。図１５に示す論理接続には、ＬＡＮ（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）またはＷＡＮ（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）といった、ネットワーク１５７２を含むが、他のネットワーク／バスを含むこともできる。そのようなネットワーク環境は、家、会社、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいて、一般的なものである。
【０２９５】
上述のように、例示的実施形態を様々なコンピューティング装置およびネットワークアーキテクチャに関連して説明したが、基礎となる概念を、データ集約型アプリケーションを開発および実行することが望ましい任意のネットワークシステム、ならびに任意のコンピューティング装置または任意のコンピューティングシステムに、適用することができる。
【０２９６】
また、例えば、適切なＡＰＩ、ツールキット、ドライバコード、オペレーティングシステム、コントロール、スタンドアロンまたはダウンロード可能なソフトウェアオブジェクトなど、同一または同様の機能を実装する複数の方法が存在し、それにより、アプリケーションおよびサービスが有効なエンコード技術および有効なクエリ技術を使用することが可能となる。このように、本明細書の実施形態を、ＡＰＩ（または他のソフトウェアオブジェクト）の観点から、およびデータスクリプト言語のための拡張可能な構文に関して提供するかまたは作動する、ソフトウェアオブジェクトまたはハードウェアオブジェクトから考察している。従って、本明細書に説明した様々な実施形態は、完全にハードウェア内、部分的にハードウェア内、ならびに、部分的にソフトウェア内、およびソフトウェア内にある態様を有することができる。
【０２９７】
用語「例示的」は、本明細書において、例、事例、または例示としての役割を果たすことを意味するよう使用する。誤解を避けるため、本明細書に開示した主題は、そのような例に限るものではない。さらに、「例示的」として本明細書に説明した如何なる態様または設計は、必ずしも、他の態様または設計より好適または有利とみなされるべきではなく、また当業者には既知の同等の例示的構造および技術を排除することを意味するものでもない。さらに、誤解を避けるため、用語「含む」、「有する」、「包含する」、および他の同様の用語を、「発明を実施するための形態」または「特許請求の範囲」のいずれかで使用する限りにおいて、そのような用語は、追加の要素または他の要素を何ら排除することなく、オープンな遷移語としての用語「備える」と同様に包括的であることを意図するものである。
【０２９８】
上述のように、本明細書に説明した様々な技術を、ハードウェアもしくはソフトウェア、または適切な場合はその両方の組み合わせに関連して実装することができる。本明細書で使用したように、用語「コンポーネント」、「システム」などは、同様に、コンピュータ関連エンティティ、ハードウェアか、ハードウェアおよびソフトウェアの組み合わせか、ソフトウェアか、または実行中のソフトウェアのいずれかに言及するよう意図するものである。例示として、コンピュータ上で実行中のアプリケーションおよびコンピュータの両方がコンポーネントであってもよい。１つまたは複数のコンポーネントが実行のプロセスおよび／または実行のスレッド内に存在することができ、コンポーネントは、１つのコンピュータ上に局在する、かつ／または２つ以上のコンピュータ間で分散してもよい。
【０２９９】
上述のシステムを、いくつかのコンポーネント間での相互作用に関して記述してきた。当然のことながら、そのようなシステムおよびコンポーネントには、それらのコンポーネントまたは指定されたサブコンポーネント、指定されたコンポーネントまたは指定されたサブコンポーネントの一部、および／または追加のコンポーネント、ならびに前述の様々な置換および組み合わせによるものを含むことができる。サブコンポーネントはまた、親コンポーネント（階層的）内に含まれたコンポーネントとしてよりむしろ、他のコンポーネントに通信可能に結合されたコンポーネントとして実装することができる。さらに、１つまたは複数のコンポーネントを、集合機能を提供する単一のコンポーネントに組み合わせるか、いくつかの別個のサブコンポーネントに分けることができること、および、統合機能を提供するためにそのようなサブコンポーネントに通信可能に結合するように、管理層といった任意の１つまたは複数の中間層を設けてもよいことに、留意すべきである。本明細書に説明した如何なるコンポーネントも、本明細書に特に説明していないが一般に当業者には既知である他の１つまたは複数のコンポーネントと、相互作用することができる。
【０３００】
上述した例示的システムを考慮した上で、説明した主題に従って実装することができる方法は、様々な図面のフロー図を参照するとよりよく理解できるであろう。説明を簡潔にするために、方法を一連のブロックとして示し説明したが、当然のことながら、特許請求の主題は、ブロックの順序には限定されない。なぜなら、ブロックのいくつかは、本明細書に示し説明するものとは異なる順序で起こってもよく、かつ／または他のブロックと同時に起こってもよいからである。不連続または分岐したフローを、フロー図を介して示している場合、当然のことながら、同一または同様の結果を達成する様々な他の分岐、フロー経路、およびブロックの順序を実装することができる。さらに、後述の方法を実装するために、図示したブロック全てを必要とするわけではない。
【０３０１】
本明細書に説明した様々な実施形態に加えて、当然のことながら、他の同様の実施形態を使用することができるか、または、対応する実施形態（単数または複数）の同一または同等の機能を実施するために、説明した実施形態（単数または複数）に、そこから逸脱することなく修正および追加することができる。またさらに、複数の処理チップまたは複数の装置が、本明細書に説明した１つまたは複数の機能の性能を共有することができ、同様に、ストレージは複数の装置に渡って効果をもたらすことができる。従って、本発明は、如何なる単一の実施形態にも限るべきものではなく、むしろ、添付の特許請求の範囲に合致する幅、精神、および範囲内にあるものとみなすべきである。
【図１】
2012504826.tif 000093
【図２】
2012504826.tif 000094
【図３】
2012504826.tif 000095
【図４】
2012504826.tif 000096
【図５】
2012504826.tif 000097
【図６】
2012504826.tif 000098
【図７】
2012504826.tif 000099
【図８】
2012504826.tif 000100
【図９】
2012504826.tif 000101
【図１０】
2012504826.tif 000102
【図１１】
2012504826.tif 000103
【図１２】
2012504826.tif 000104
【図１３】
2012504826.tif 000105
【図１４】
2012504826.tif 000106
【図１５】
2012504826.tif 000107
【国際調査報告】
2012504826.tif 000108
2012504826.tif 000109