JP6046346B2 - 宣言データのスクリプト言語のための型システム - Google Patents

Description

本主題の開示は、一般的に宣言データのスクリプト言語のための、表現に富み、コンパクトで柔軟な型システムに関する。

一般的な背景として、スクリプト言語はソフトウェアシステム、アプリケーション、およびプログラムを制御するプログラミング言語である。スクリプトは、他のアプリケーションとは独立して実行する「プログラム」と区別されるものとして扱われることが多い。その上、スクリプトは、別の言語で書かれたアプリケーションの「コアコード」と区別できる。スクリプトは、開発者、または、他のプログラムによりソースフォーマットもしくはオブジェクトフォーマットで、ヒューマンフレンドリ、マシンフレンドリ、またはそのいずれでもないとの観点から全領域にわたって書くことができる。エンドユーザにアクセス可能な範囲では、スクリプトはアプリケーションの動きをユーザのニーズに適応することができる。また、スクリプトはソースコードから解釈する、またはバイトコードあるいは別のマシンフレンドリなフォーマットに準コンパイル化して解釈することもできる。スクリプト言語は、関連付けされるアプリケーションに組み込むこともできる。

さらなる背景として、型システムは、プログラミング言語がどのように値および式（ｅｘｐｒｅｓｓｉｏｎ）を型に分類し、プログラミング言語がそれらの型をどのように操作するか、それらの型がどのように相互に対話するかを定義する。型は値または値の集合を、特別な意味または目的を有するものとして識別する。但し幾つかの型、例えば抽象型および関数型は実行プログラムの値としては表現されないかもしれない。型システムは言語間で大きく異なり、例えば、他の異なる種類の中でも、型システムは言語のコンパイル時間の構文規則の実装および実行時間の運用の実装と共に変化し得る。

型をどのように使用できるかの例としては、コンパイラは静的な型の値を使用して、アルゴリズムのストレージおよび選択を、値を運用するために最適化できる。例えば、多くのＣコンパイラにおいて、名称上型付けられている「浮動（ｆｌｏａｔ）」データ型は、単精度浮動小数点数の承認基準に従って、３２ビットで表現される。従って、Ｃは浮動小数点固有の運用をこれらの値、例えば、浮動小数点加算、乗算、等に用いる。さらに、型の制約の程度および型の評価の方法は言語の型付けに影響を及ぼすことができる。

幾つかのケースにおいて、開発者すなわち人は、ソースコードを定義するテキストを作成し、コンパイラは所与のプラットフォームがオブジェクトコードを実行するために言語を１つ以上のマシンフレンドリなフォーマットに変換する。他のケースにおいて、アプリケーションまたはマシン自体が、コード生成時に人を介さずデータストアを通して実行するためのコードを生成できる。どちらのケースにおいても、効率のよい論理的および表現に富んだ型システムは、言語をコンパクトに保つことが望まれるばかりでなく、効率よく、構造的にコンパクトなデータ集約型アプリケーションを効率の良いストレージ表現に合わせ生成できるように、高度に表現力がありかつ論理的であることが望まれる。しかし、従来のプログラミング言語の型システムは、複雑な大規模データの処理と消費に対して、一般性に欠け、柔軟性も十分ではない。簡潔に述べると、型システムの複雑性、または柔軟性の欠如および関連する非効率性は、大量のデータが関連してくると指数関数的に、またはバランスを失って巨大化する。

従って、一連のサーバコンピュータが長時間に亘るデータの大量の記録、またはトランザクションを収集するときのように、大量のデータがデータベースに格納されるときに、開発者、他のコンピュータ、他のアプリケーション等は、１つ以上のスクリプトを介してそのデータに、またはそのデータの対象とするサブセットに、アクセスを望むことがある。そのようなスクリプトについてプログラミン構文の型が効率的であること、および表現可能である生成されたデータ構造が結果的に簡易であることは、特にそのスクリプトが大量のデータに対して働くときに重要な目標となる。事例として、１つ以上の方法、スクリプト、またはプログラムを介して、あるデータの特定のサブセットに対する問い合わせ、データの読み出し書き込み、データの更新、またはそのデータへの他の任意の処理の適用が望まれる可能性がある。コンピューティング全領域（ｃｏｍｐｕｔｉｎｇ ｕｎｉｖｅｒｓｅ）において、データ値が多様であるとすると、型を豊富にかつ有効に表す能力は、データ集約型アプリケーションおよびプログラムにもたらされる性能を著しく改善できる。このように、大規模なデータ処理システムに対して、現在の型システムのこれらおよび他の不足部分を解決する型システムが備わったプログラミング言語が長い間求められてきた。

上記した背景の情報および現在あるプログラミング言語の型システムの欠陥部分は、幾つかの背景情報および従来からあるシステムの問題点の全体像を提示することを単に意図したものであり、全て網羅することを意図しない。本明細書で記述する従来システムに関する他の問題点および様々な非限定的実施形態に見合った利点が、下記の説明を再検討することによりさらに明らかになろう。

本明細書において、簡略化した概要が、より詳細な記述および添付図に沿った様々な態様の例示的かつ非限定的実施形態の基本的または全体的理解を得るために提供される。しかし、本概要は、広範囲で全体を網羅する総覧であることを意図していない。代わりに、本概要の唯一の目的は、下記に示す様々な実施形態のより詳細な「発明を実施するための形態」の前書きとして簡略化した形式で、幾つかの例示的非限定的な実施形態に関する幾つかの概念を提示することにある。

効果的で構造的にコンパクトなデータ集約型アプリケーションが作成できるように、効果的、論理的、および表現に富んだ型システムの様々な実施形態が、宣言型プログラミング言語の型を柔軟に定義するために提供される。一非限定的態様において、型システムはリファインメント型および型メンバシップ式の組み合わせを支援する。他の非限定的態様の中で、メンバとして有効な値全てを包括するトップ型（ｔｏｐ ｔｙｐｅ）と組み合わせることにより、型は他の型の共通集合および／または和集合として表現できる。このように、型は実世界データの大規模コレクションの形で見出される、データの型全領域に対して効率よく表現できる。

これらおよび他の実施形態を下記にさらに詳述する。
様々な非限定的実施形態が、添付の図を参照してさらに記述される。

宣言型プログラミング言語および関連構造に対するコンパイルプロセス連鎖のブロック図である。 本明細書で記述する１つ以上の実施形態における、型システムの例示的態様を説明する第１のブロック図である。 本明細書で記述する１つ以上の実施形態における、型システムの例示的態様を説明する第２のブロック図である。 本明細書で記述する１つ以上の実施形態における、型システムの例示的態様を説明する第３のブロック図である。 複数の型の共通集合となり得る型システムを説明するブロック図である。 複数の型の結合または和演算の実行が可能な型システムを説明するブロック図である。 トップ型をヌル型に対して否定可能にするシステムを説明するブロック図である。 実施形態に従って型リファインメントおよび型メンバシップを支援する型システムを備えた宣言型プログラミングモデルに基づいて宣言コードを定義するためのプロセスを説明するフロー図である。 実施形態に従って高機能型システムを有する宣言型プログラミングモデルに基づいて宣言コードを実行するためのコンピューティングシステムのブロック図である。 実施形態に従ってコンピューティングデバイスの少なくとも１つのプロセッサにより宣言コードを実行するためのプロセスを説明するフロー図である。 実施形態によりパッケージ化された宣言モデルに対する例示的プロセス連鎖を示す図である。 記録本位実行モデルに関連付けられる型システムを説明する図である。 実施形態に従って制約ベースの実行モデルに関連付けられる型システムの非限定的説明の図である。 順序付け実行モデルに従ってデータストレージを説明する図である。 順序に依存しない実行モデルに従ってデータストレージの非制限を説明する図である。 本明細書で記述する様々な実施形態を実装できる、例示的非制限ネットワーク環境を表わすブロック図である。 本明細書で記述する様々な実施形態の１つ以上の態様を実装できる、例示的非制限コンピューティングシステムまたは動作環境を表わすブロック図である。

概説
「背景技術」で記述したように、とりわけ従来の型システムは、作成したプログラムの表現力に制限を与え、得られたストレージ構造ならびにアルゴリズム的処理の効率に制限を与える、ある種の煩雑さならびに柔軟性の欠如を有する。従来のシステムの上記弱点は、大規模データストレージおよび処理システムに関連するような規模の大きい状態で遂行するときに特に実感される。

Ｄはマイクロソフトにより設計されたプログラミング言語であり、データ集約型プログラムを作成するのに非常に適している。Ｄの型付け（ｔｙｐｉｎｇ）システムは、複数の異なる型のプログラムの和集合および／または共通集合を表す能力を含むがそれに限定されない言語表現の相乗効果を可能にする固有の機能の組み合わせを支援する。事例として、一実施形態において、型システムはリファインメント型および型メンバシップの式の組み合わせを支援する。型システムは、またメンバとして有効な全ての値を包括するトップ型を含む。

Ｄプログラミング言語は、宣言型プログラミングモデルおよび言語に対し上記の型システムに関して、本明細書で説明する様々な実施形態のコンテキストとして提供される。しかし、本明細書で記述する様々な実施形態は、プログラミング構文および他の定義付け特性に関して、Ｄと同一または類似の能力を有する任意の宣言型プログラミング言語に適用できる。

この点に関して、命令型プログラミング言語に対応するものとしてよく見なされる宣言型プログラミング言語でソースコードを作成することがしばしば望ましい。命令型プログラミング言語とは異なり、宣言型プログラミング言語は、所与の技術またはプラットフォームに対してユーザのニーズに合う方法を指定しなければならないこともなく、ユーザが自分のデータから希望するデータ全てを書くことができる。このように、Ｄは例示的疑似コードや概念説明に適したソースではあるが、Ｄプログラミング言語で叙述される実施形態だけではなく、本明細書では１つ以上の実施形態で説明する型システムを含む任意の宣言型言語を考える。

この点に関して、その詳細を下記に示すが、Ｄプログラミング言語は、コンパクトで、人が理解できる表現であることに適した宣言型プログラミング言語であり、フラッシュストレージ、リレーショナルデータベース、ＲＡＭ、外付けドライブ、ネットワークドライブ、等に関わらず、基礎となるストレージ機構とは独立して、データ集約型アプリケーションを作成、変更するのに効率の良い構文を有利に含んでいる。また「Ｄ」は、ときには「Ｍ」プログラミング言語と称されるが、一貫性のため本明細書ではＭを使用しない。

Ｄは、宣言ソースコードを書くのに効率的でコンパクトな構文規則を含んでおり、それには言語の使用、例えばデータ集約型アプリケーションに対して強力な権限を与える能力を有する型システムが含まれる。より具体的には、本明細書で記述するように本型システムにより、表現に富んだ型システムを使用して、データ集約型アプリケーションを静的に検証できる。この点に関して、一実施形態において、「トップ」型（Ｄでは「Ａｎｙ」と表記）とリファインメント型（ここで、型は任意のブール式により条件付け可能）、およびリファインメント式の言語で型判別式の算入の組み合わせである。

データスクリプト言語の型システム
データスクリプト言語の型システムに対して本実施形態に関する追加の詳細が以下に記述されるが、最初に一部のコンテキストが、Ｄコンパイル連鎖に基づいてＤプログラムを表現および使用できる種々の方法に関して、図１に説明される。たとえば、ソースコード１００は、開発者または機械により直接作成可能である。ソースコード１００は、次にたとえばソースコード１００を解析するためのＤ構文解析ツール１２０、Ｄ構文木形成のためのＤ構文木コンポーネント１３０を含めてＤコンパイラ１１０によってコンパイルされ、それらはその後解析されＤグラフ構造１４０に変形できる。

Ｄグラフ構造１４０は、直接開発者により、またアプリケーションにより生成され、簡単な方法で表現することが可能である。Ｄグラフ構造１４０は、構文木１３０までほどき、さらにソースコード１００に引き返すことができ、またＤグラフ構造１４０は、ＳＱＬデータベースクエリ、企業データ管理（ＥＤＭ＝ｅｎｔｅｒｐｒｉｓｅ ｄａｔａ ｍａｎａｇｅｍｅｎｔ）、表計算アプリケーション、グラフィックアプリケーション、すなわちデータが格納および解析できる場所のような、様々なドメイン特定使用１５０に従うデータ集約型アプリケーションに関連してオブジェクトコードにコンパイルまたは準コンパイル化できる。

Ｄプログラミング言語のような型付け言語は、言語の変数が見込まれる値の範囲に境界が設定されるという考え方をする。その範囲の境界上限を型と呼んでいる。型システムは、変数の型、および一般的には、プログラムの式全体の型を追跡する型付け言語のコンポーネントである。「Ｄ」で指定およびチェック可能な型は従来のシステムでは不可能であり、そのような型を、以下により詳細に記述する。

様々な非限定の実施形態で述べるように、本発明は簡単ではあるが機能の豊富な型言語が可能になるリファインメント言語のリファインメント型および型判別式を組み合わせたデータスクリプト言語の型システムを提供する。一実施形態において、リファインメント言語のリファインメント型および型判別式との組み合わせで、さらなる表現力のある型言語を生成するトップ型が支援される。この表現に富む型システムを使用すると、データ集約型アプリケーションを静的に検証できる。

図２のブロック図で示すように、一実施形態において、Ｄプログラミング言語のような宣言型プログラミング言語は、プログラムの一部を形成する様々なプログラミング構文２００を含む。システム、アプリケーション、サービスは、そのような構文２００を特定し、データストア（複数可）２６０に対してＤプログラムとしてそれら構文を実行し、データ集約結果を達成できる。一つの非限定な態様において、プログラミング構文２００の基礎であるプログラミングモデルの型システム２５０は、リファインメント型２１０とリファインメント型２１０の式内の型メンバシップ評価２２０の組み合わせの支援を含む。この点に関して、リファインメント型およびリファインメント型の式内にある型メンバシップ評価の支援の組み合わせは、従来のシステムでは支援されない。

図３のブロック図で示すように、型システム２５０の能力に加えて、型システム３５０は、また有効値全てを包括するトップ型３３０を含むことが可能である。言い換えると、そのトップ型は、トップ型を有するプログラミングモデルで見られるあらゆる型の内で最も制約の少ない型である。図４のブロック図で示すように、他の能力に加えて、型システム４５０は、型としての値４２０、また値としての型４１０の支援を随意的にさらに含むことができる。

「Ｄ」の型は、コレクション型、Ｔ^*（と表記）（型Ｔの値のコレクションを意味する）、およびエンティティまたは記録型、｛１１：Ｔ１，．．．ｌｎ：Ｔｎ｝（と表記）（型Ｔ１，．．．Ｔｎに個々に対応するフィールドｌ１，．．．ｌｎを有するエンティティを意味する）と共に、Ｉｎｔｅｇｅｒ（整数）、Ｔｅｘｔ（テキスト）、Ｌｏｇｉｃａｌ（論理）のような基本型を含む。

データスクリプト言語に対する上記型システムの一実装において、型システムは「トップ」型（Ａｎｙと表記）を支援する。全ての有効Ｄ値はこの「制約最小限」型の値である。さらに、ｖａｌｕｅが識別子、Ｔが型、ｅがブール値の式である｛ｖａｌｕｅ：Ｔ｜ｅ｝と表記可能であるリファインメント型が支援されており、例えばリファインメント型に対する「Ｄ」構文は単純に「Ｔ ｗｈｅｒｅ ｅ」である。そのような型の値は、ブール式ｅが真である、型Ｔの有効「Ｄ」値である。

例えば、値４２が型｛ｘ：Ｉｎｔｅｇｅｒ｜ｘ＞４１｝のメンバであるのは、値４２の型は整数（Ｉｎｔｅｇｅｒ）であり、４２は実際に４１より大なので判別ｘ＞４１を満足するからである。さらなる例として、値４３もまたこの型のメンバであるが、しかし値４０はメンバではない。さらに、型システムはリファインメントでブール値の式を支援する。ブール式の書式は、「ａｎｄ」、「ｏｒ」、「ｎｏｔ」、「ｉｍｐｌｉｅｓ」を支援し、さらに、型システムは、型「ｅ ｉｎ Ｔ」と表記される型メンバシップ判別、または型判別式を含む。型判別式の運用上の動きは、式ｅを評価すること、および得られる値が型Ｔの値の集合にあるかを決定することである。

この点に関して、型システムの上記特徴を組み合わせると、型定義に対して幾つかの強力で、洗練された式をもたらす。例えば、図５は、第１の非限定な利点を説明している。その利点とは、制約ベースのまたは構造の型付けにより、その両方が定義される第１の型５００および第２の型５１０の共通集合である、単一でコンパクトな式で型５２０を定義できることである。型Ｓおよび型Ｔの共通集合の型は次のように表すことができる。
｛ｘ：Ａｎｙ｜ｘｉｎＴ＆＆ｘｉｎＳ｝

図６は、別の非限定な利点を説明している。すなわち、制約ベースのまたは構造の型付けにより、その両方が定義される第１の型６００および第２の型６１０の和集合である、単一でコンパクトな式で型６２０を定義できることである。型Ｓおよび型Ｔの和集合の型は、次のように表すことができる。
｛ｘ：Ａｎｙ｜ｘｉｎＴ｜｜ｘｉｎＳ｝

トップ型またはトップレベル型を有する型システムの別の非制限な利点は、図７で示されるように、空（ｅｍｐｔｙ）型もまた表現できることである。トップ型「Ａｎｙ」を否定することにより、ヌル型７２０は、無効型の集合と表現できる。Ｄでは、ヌル型は次のように表現できる。
｛ｘ：Ａｎｙ｜ｆａｌｓｅ｝

理解を深めるため、型システムは判定のコレクションを用いて数学的に記述できる。判定は次の形をとる。

ここで、

はあるアサーションであり、その自由変数はΓで宣言される。コンテキストΓは、書式φ，ｘ１：Ｔ１，．．．，ｘｎ：Ｔｎ．（空コンテキストφは、時には省略される）形式の個別の変数およびそれらの型の順序付けリストである。

型システムの一次判定形式は、式ｅがコンテキストΓで型Ｔを有するとアサートする型付け判定であり、例えばｅの自由変数がΓで定義される。これは、次のように記述される。
Γ├ｅ：Ｔ

アサーションｅ：Ｔ、すなわち式ｅが型Ｔを有することのアサーションは１つの関係である。言い換えると、所与の式は多くの型を持っていると言える。式ｅは、Γ├ｅ：Ｔなる型Ｔが存在すると、コンテキストΓで上手く型付けができると言える。（正式な）型システムは、型規則の集合を与えることにより特定可能である。この型規則は、有効であると推定する他の判定を基本に、ある判定の有効性を定義するものである。

他の判定形式は、型Ｓが別の型Ｔの下位の型（ｓｕｂｔｙｐｅ）であることをアサートする下位の型付け（ｓｕｂｔｙｐｉｎｇ）判定であり、以下に記す。
Γ├Ｓ＜：Ｔ

「Ｄ」プログラミング言語の型システムは、上記判定を定義する型規則の集合を与えることにより正式に指定できる。例えば、型判定式が適正に型付けを行ったかの決定は、次の型規則により定義される。

言い換えると、Ｔの式ｅは、式がある型Ｓであると、コンテキストΓで適正に型付けられる（および型が論理的（Ｌｏｇｉｃａｌ）である）。

別な規則により下位型付けが導入される。

この規則は、式ｅがコンテキストΓで型Ｓであり、およびさらにＳがＴの下位の型である場合、式ｅは、また型Ｔでもあることを述べている。

式が型Ａｎｙかを決定する規則は、以下のようである。

式がリファインメント型かを決定する規則は、以下のようである。

言い換えると、式ｅ１がコンテキストΓで型Ｔであり、式ｅ２がコンテキスト（Γ，ｘ：Ｔ）で型Ｌｏｇｉｃａｌであり、およびｘに代入したｅ１を有するブール式ｅ２が論理的に真であると決定できる場合（この事実の決定にある補助ルーチンｃｈｅｃｋ＿ｉｓ＿ｔｒｕｅ（チェックが真）を仮定する）、式ｅ１は、型｛ｘ：Ｔ｜ｅ２｝である。有効な判定の誘導の例は以下のようである。

リファインメント式が満足される補助チェック（ｃｈｅｃｋ＿ｉｓ＿ｔｒｕｅ）は、代替的に型システムにより実行されない可能性があるが、実行時にチェックされるよう式中に挿入可能である。

従って、上記のように型システムを実装することにより、また上記規則および判定に準拠して、表現に富んだ型が、静的に検証できるプログラムの一部として特定可能である。

図８は、型リファインメントおよび型メンバシップを支援する型システムを備えた宣言型プログラミングモデルに従って、宣言コードを定義するプロセスを説明するフロー図である。８００では、宣言型プログラミング言語のプログラミング構文（複数可）の仕様が、コンピューティングシステム、デバイス、アプリケーションまたはサービスによって受信される。８１０では、ここで、リファインメント型構文を特定するプログラミング構文の受信を含むことができる。このリファインメント型構文は、１つ以上の型をブール式が真である値を特定することにより定義するものである。８２０で示されるように、ここで、型リファインメント構文内で、式評価の１つ以上の結果として得られる値が指示された型のメンバであるかどうかを決定する型メンバシップ判別構文の仕様の受信を含むこともできる。８３０では、コードの機械可読表現が、プログラミング構文（複数可）の仕様に基づいて生成できる。好都合にも、型システムにより、種々の型の共通集合演算および／または和集合演算ができるが、この可能性は限定されるものではない。

図９は、データストア（複数可）９５０に通信可能に接続されたデータ処理システム９２０を含むシステムのブロック図であり、宣言コードでデータの集約的処理を実行するためのものである。この点に関して、システム９２０は、制約ベースの型リファインメントおよび型メンバシップを支援する型システム９１０を実装する宣言コードモジュールを含む。宣言コード９３０は、基礎的型システム９１０を支援する宣言型プログラミングモデル９００により特定されるが、この基礎的型システム９１０は、全ての型を表現する非限定トップレベル型に関する型を構築することにより型を定義する型システムのリファインメント型を支援する。その上、リファインメント型は、指示された型のメンバシップに対する式の評価判別をする型判別構文を含むことができる。さらに、型チェックコンポーネント９４０は、プログラミング構文の型付けの有効性を定義する少なくとも１つの規則を基本として、エラーを判定するため、宣言コードの型を評価する。また、記述したように、本明細書の何れの実施形態も、プログラミング言語のコンテキストにあり、型は値を有することができ、値は型を有することができる。

図１０は、コンピューティングデバイスの少なくとも１つのプロセッサよって、宣言コードを実行するためのプロセスを説明するフロー図である。１０００では、宣言型プログラムが受信されるが、宣言型プログラムは、宣言型プログラムのプログラミング構文内で、リファインメントによる型付け、型メンバシップの評価、および宣言型プログラムの全ての有効値がメンバであるトップ型を支援する型付けシステムに従って特定される。１０１０では、宣言型プログラムを、値を有する型および型を有する値を支援する型付けシステムに従い、随意的に指定できる。１０２０では、宣言型プログラムで表現される型は、型付け規則の集合および型付けシステムに関連付けした判定に従って、型チェックされる。１０３０では、宣言型プログラムの実行、ストレージ、または変更が実施できる。

例示的な宣言型プログラミング言語
疑問を回避するため、Ｄプログラミング言語のような宣言型プログラミング言語に関して、本細目で提供した追加のコンテキストは、完全には網羅したものではなく、また限定を行ったものでもないと考えられるべきである。以下に述べる疑似コードについてのほんの一部の特別な例は、実例および解説のみを目的としており、様々な詳細で上記したデータスクリプト言語の型システムの実施形態を限定すると考えるべきではない。

図１１では、Ｄプログラミング言語を基本とするモデルのような、宣言モデルの例示的プロセス連鎖が提供される。説明のように、プロセス連鎖１１００は、コンパイラ１１２０、パッケージコンポーネント１１３０、同期コンポーネント１１４０、および複数のレポジトリ１１５０、１１５２、．．．、１１５４の結合を含むことができる。上記実施形態内では、コンパイラ１１２０へ入力されたソースコード１１１０は、Ｄプログラミング言語のような宣言型プログラミング言語で作成された宣言型実行モデルを表す。Ｄプログラミング言語で、たとえば、ソースコード１１１０により具現化した実行モデルは、制約ベースの型付けまたは構造的型付けに有利に従い、および／またはコード開発を簡略化するため、順序に依存しない、または順序無しの実行モデルを有利に具現化する。

コンパイラ１１２０は、ソースコード１１１０を処理し、各ソースコードに対して、後処理の定義を生成できる。他のシステムは、コンパイルを命令フォーマットに至るまで実行するが、ソースコードの宣言フォーマットは、変形の間維持される。パッケージコンポーネント１１３０は、Ｄプログラミング言語のケースにおいて、Ｄ＿Ｉｍａｇｅファイルのように、特別なレポジトリ１１５０、１１５２、．．．、１１５４にインストール可能なイメージファイルとして、後処理の定義をパッケージ化する。イメージファイルは、必須メタデータおよび宣言ソースモデルと共に複数の変形されたアーティファクトを格納するためのそれらの拡張可能ストレージの定義を含む。例えば、パッケージコンポーネント１１３０は、特別なメタデータプロパティを設定でき、イメージファイルのコンテンツの部分としてのコンパイラ出力アーティファクトと共に、宣言ソース定義を格納できる。

Ｄプログラミング言語で、パッケージコンポーネント１１３０が使用するパッケージフォーマットは、ＥＣＭＡ（欧州電子計算機工業会） ＯＰＣ（Ｏｐｅｎ Ｐａｃｋａｇｅ Ｃｏｎｖｅｎｔｉｏｎ）標準に準拠する。当業者であれば、この標準は、圧縮、グループ化、署名、等のような特徴を本質的に提示していることを容易に理解するであろう。この標準は、またパブリック・プログラミング・モデル（ＡＰＩ）を定義し、それにより、イメージファイルが標準プログラミングツールを介して操作可能となる。例えば、．ＮＥＴ Ｆｒａｍｅｗｏｒｋにおいて、ＡＰＩは、「Ｓｙｓｔｅｍ．ＩＯ．Ｐａｃｋａｇｉｎｇ」の名前空間内で定義される。

同期コンポーネント１１４０は、イメージファイルを管理するのに使用可能なツールである。例えば、同期コンポーネント１１４０は、イメージファイルを入力として扱い、そのファイルを参照イメージファイルの集合とリンクできる。その操作の間に、またはその後に、パッケージ化されたアーティファクトを引き出して、それらを処理し、さらに同一のイメージファイルにさらにアーティファクトを加えることにより、イメージファイル上で動作する（リライタ、オプチマイザ、等のような）種々の支援ツールが可能である。これらのツールは、また、イメージファイルの幾つかのメタデータを巧みに操作して、例えば、整合性および安全性の確証のため、イメージファイルにデジタルに署名することなどの、イメージファイル状態を変更できる。

次に、展開ユーティリティは、イメージファイルを展開し、またインストールツールは、イメージファイルをリポジトリ１１５０、１１５２、．．．、１１５４内の動作実行環境にインストールする。イメージファイルが展開されると、イメージファイルは、エクスポート、検出（ｄｉｓｃｏｖｅｒｙ）、サービス、バージョニング（ｖｅｒｓｉｏｎｉｎｇ）、アンインストール、およびさらに多くの機能を含む様々な後展開のタスクを被る可能性がある。Ｄプログラミング言語を使用すると、パッケージフォーマットは、これら全ての運用の支援を提供し、一方さらに安全性、拡張性、可変サイズ能力、および性能のような企業レベルの産業要件を満たす。一実施形態において、リポジトリ１１５０は、リレーショナルデータベース管理システム（ＲＤＢＭＳ＝ｒｅｌａｔｉｏｎａｌ ｄａｔａｂａｓｅ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ）のコレクションが可能であるが、何かしらのストレージを搭載してもよい。

一実施形態において、本明細書で記述する方法は、制約ベースの型システムを有するプログラミング言語で運用可能である。そのような制約ベースのシステムは、従来の名目上の型システムでは、簡単には利用できない機能性を提供する。図１２、図１３において、名目上の型付け実行システムが、本発明の実施形態に従って制約ベースの型付け実行システムと比較される。説明のように、名目上のシステム１２００は、どの値に対しても特別の型を割り当てるが、それに対して、制約ベースのシステム１２１０の値は、任意の無数の型に適合できる。

名目上の型付け実行モデルおよびＤプログラミング言語のような、本明細書で記述した宣言型プログラミング言語による制約ベースの型付けモデルとの対比を説明するために、各モデルの型宣言に対する例示的コードが以下で比較される。

最初に、名目上の型付け実行モデルに関して、次の例示的Ｃ＃コードの例を説明する。すなわち、
ｃｌａｓｓ Ａ
｛
ｐｕｂｌｉｃ ｓｔｒｉｎｇ Ｂａｒ；
ｐｕｂｌｉｃ ｉｎｔ Ｆｏｏ；
｝
ｃｌａｓｓ Ｂ
｛
ｐｕｂｌｉｃ ｓｔｒｉｎｇ Ｂａｒ；
ｐｕｂｌｉｃ ｉｎｔ Ｆｏｏ；
｝

この宣言に対して、型と値には堅固な関係が存在し、ＡとＢの値は、それらのフィールドの値ＢａｒとＦｏｏが一致していても、比較できないと考えられる。

対照的に、制約ベースのモデルに関して、次の例示的Ｄコード（下記により詳細に記述）は、オブジェクトが幾つかの型に適合できる方法について説明している。すなわち、
ｔｙｐｅ Ａ ｛Ｂａｒ：Ｔｅｘｔ；Ｆｏｏ：Ｉｎｔｅｇｅｒ；｝
ｔｙｐｅ Ｂ ｛Ｂａｒ：Ｔｅｘｔ；Ｆｏｏ：Ｉｎｔｅｇｅｒ；｝

この宣言に対して、型と値の関係は、型Ａに適合する全ての値はＢに適合し、その逆も同様であるように、非常に柔軟性に富んでいる。さらに、制約ベースのモデルの型は、互いのトップにレイヤとして置くことができ、例えば、様々なＲＤＢＭにわたり、プログラミングに役立つ柔軟性を提供する。実際に、制約ベースのモデルの型は、初期では全領域（ｕｎｉｖｅｒｓｅ）全ての値を含んでいるため、特定の値は、値が型宣言でコード化される制限を侵さない全ての型と適合可能である。このように、宣言ｔｙｐｅ Ｔ：Ｔｅｘｔ ｗｈｅｒｅ ｖａｌｕｅ＜１２８によって定義された型と適合可能である値の集合は、「Ｉｎｔｅｇｅｒ（整数）」という制約または「ｖａｌｕｅ＜１２８」という制約を侵さない「全領域全ての値」を含む。

このように、一実施形態において、ソースコードのプログラミング言語は、上記のように、Ｄプログラミング言語で実装されるような、制約ベースの型システムを含む純粋な宣言型言語である。

他の実施形態において、本明細書で記述する方法は、また順序に依存しないまたは順序無しの実行モデルを有するプログラミング言語で運用することも可能である。上記の制約ベースの実行モデルと同様に、そのような順序に依存しない実行モデルは、例えば、様々なＲＤＢＭＳにわたって、プログラミングするのに役立つことができる柔軟性を提供する。

図１４、図１５において、説明の目的のために、順序付け実行モデルに従ったデータストレージ抽象化が、順序に依存しない実行モデルによるデータストレージ抽象化と比較される。例えば、図１４のデータストレージ抽象化１４００は、順序付け実行モデルに従って作成されたリストＦｏｏを表し、それに対して、図１５のデータ抽象化１４１０は、順序に依存しない実行モデルにより作成された同様なリストＦｏｏを表す。

説明されているように、データストレージ抽象化１４００および１４１０の各々は、３つのＢａｒ値の集合（すなわち、「１」、「２」、および「３」）を含む。しかし、データストレージ抽象化１４００は、これらＢａｒ値が、特定の順序で入力またはリスト化されるよう要求し、それに対して、データストレージ抽象化１４１０は、そのような要求は全くしない。代わりに、データストレージ抽象化１４１０は、各Ｂａｒ値にＩＤを単に割り振るが、ここにおいて、これらＢａｒ値が入力／リスト化された順序は、対象リポジトリにとって認識されない。事例として、データストレージ抽象化１４１０は、このように下記の順序に依存しないコードから生じることができる。
ｆ：Ｆｏｏ^*＝｛Ｂａｒ＝“１”｝；
ｆ：Ｆｏｏ^*＝｛Ｂａｒ＝“２”｝；
ｆ：Ｆｏｏ^*＝｛Ｂａｒ＝“３”｝；

しかし、データストレージ抽象化１４１０は、また下記のコードからも生じることができる。
ｆ：Ｆｏｏ^*＝｛Ｂａｒ＝“３”｝；
ｆ：Ｆｏｏ^*＝｛Ｂａｒ＝“１”｝；
ｆ：Ｆｏｏ^*＝｛Ｂａｒ＝“２”｝；

さらに、上記２つのコードの各々は、機能的に下記のコードに等価である。
ｆ：Ｆｏｏ^*＝｛｛Ｂａｒ＝“２”｝，｛Ｂａｒ＝“３”｝，｛Ｂａｒ＝“１”｝｝；

上記の制約ベースの型付けおよび順序無しの実行モデルに互換性がある例示の宣言型言語は、Ｄプログラミング言語であり、時には本明細書で便宜上「Ｄ」と称し、本発明の譲受人により開発された。しかし、Ｄに加えて、他の類似の宣言型プログラミング言語が使用可能であること、および本発明のユーティリティは、如何なる単一のプログラミング言語に対しても限定されないことは理解すべきであり、上記方向付けしたグラフ構造の１つ以上の如何なる実施形態も該当するものである。この点について、Ｄに関するある追加的コンテキストが、以下に提供される。

述べてきたように、Ｄはデータを扱うための宣言型言語である。Ｄはユーザに、作成可能であり可読である両方を備えた使い勝手が良いテキスト構文規則を用いて、ユーザデータ構築およびユーザデータ問い合わせのユーザが望む方法をユーザに決定させる。１つの非限定態様において、Ｄプログラムは、コンパイルユニットとして公知の１つ以上のソースファイルを含み、このソースファイルは、順序付けされた一連のユニコード文字（Ｕｎｉｃｏｄｅ ｃｈａｒａｃｔｅｒ）である。ソースファイルは、一般的に、ファイルシステムのファイルに１対１に対応しているが、この対応は必須ではない。移植性を最大限にするため、ファイルシステムのファイルをＵＴＦ−８エンコードで符号化することが推奨される。

概念的に述べると、Ｄプログラムは、４つのステップを使用してコンパイルする。すなわち、１）字句解析（字句解析は前処理指令を評価、実行する）、これはユニコード入力文字のストリームをトークンのストリームに変換するもの、２）構文規則解析、これはトークンのストリームを抽象的構文木に変換するもの、３）セマンティック解析、これは、全ての符号を抽象的構文木に分解し、型は構造をチェックし、セマンティックグラフを生成するもの、および、４）コード生成、これは、ある対象とする実行時間（例えば、ＳＱＬ、イメージを作成）に対してセマンティックグラフから実行可能命令を発生するものである。さらに、ツールはイメージとリンクができ、それらを実行時間にロードできる。

宣言型言語のように、Ｄはデータが格納されるまたはアクセスされる方法を強制しないし、また命令する特定実装技術（ＸＡＭＬのようなドメイン固有言語と対照的に）もまた強制しない。むしろ、Ｄは、ユーザデータから、ユーザが所与の技術またはプラットフォームに対して満足できる方法を指定する必要なく、欲しいデータをユーザが書き込みできるようにされていた。このことは、Ｄが、Ｄ構文を所与の環境で表現および実行する方法を制御するために、機能性に富んだ宣言的または命令的支援を実装が行うことを決して禁じていないことを意味し、それ故に、開発性に富んだ柔軟性を可能にしている。

Ｄは３つの基本概念、値、型、およびエクステントの上に構築されている。これら３つの概念は、次のように定義できる。１）値はＤ言語の規則に準ずるデータである、２）型は値の集合を表現する、３）エクステントは値に対して動的なストレージを提供する。

一般的に、Ｄはデータの型付けを、データのストレージ／エクステントから切り離す。また、所与の型を使用して、演算の結果を記述するのと同様に複数のエクステントからのデータを記述できる。これにより、ユーザは、最初に型を書き始めることができ、その後対応する値の場所の決定または値の計算ができる。

値を置く場所の決定を主題とすると、Ｄ言語は、実装が宣言されたエクステントをＲＤＢＭＳのような外部ストアにマッピングする方法を指定しない。しかし、Ｄはそのような実装を可能にするように作成されていたのであり、またリレーショナルモデルと互換性がある。

データ管理に関しては、Ｄは、エクステントのコンテンツの変更に対する構文を有しない関数型言語であるが、しかし、Ｄは、エクステントのコンテンツが、外部（Ｄに対して）刺激を介して、変更可能であることは見込んでおり、また、Ｄは随意的に、データを更新するための宣言構文を提供するよう修正できる。

検証または割当ての目的上、値を分類する方法を書きだすことはしばしば望ましい。Ｄにおいて、値は、型を使用して分類され、そこではＤ型は受領可能または規則に準拠した値のコレクションを表現する。さらに、Ｄ型は特定のコンテキスト（例えば、オペランド、ストレージの場所）にどの値が出現するのか制約するのに使用される。

留意すべき若干の例外はあるが、Ｄは型をコレクションとして使用することを可能にする。例えば、オペレータ「ｉｎ」を使用して、値が所与の型に適合しているか判別できる。例えば、
１ ｉｎ Ｎｕｍｂｅｒ
“Ｈｅｌｌｏ，ｗｏｒｌｄ” ｉｎ Ｔｅｘｔ

埋め込み型の名称は、Ｄ言語で直接利用可能であることに留意されたい。しかし、また型に対する新規の名称は、型宣言を使用し導入することもできる。例えば、下記の型宣言は、「Ｔｅｘｔ」単純型に対して、同義語として型の名前「Ｍｙ Ｔｅｘｔ」を取り込む。
ｔｙｐｅ ［Ｍｙ Ｔｅｘｔ］：Ｔｅｘｔ；

次に、利用可能なこの型の名前について、次のコードが書かれる。
“Ｈｅｌｌｏ，ｗｏｒｌｄ”ｉｎ［Ｍｙ Ｔｅｘｔ］

既存型にカスタム名を導入することは有用である一方、この型宣言は、基礎型に述語（ｐｒｅｄｉｃａｔｅ）を適用するのにさらに有用である。例えば、
ｔｙｐｅ ＳｍａｌｌＴｅｘｔ：Ｔｅｘｔ ｗｈｅｒｅ ｖａｌｕｅ．Ｃｏｕｎｔ＜７；

この例において、可能な「Ｔｅｘｔ」値の全領域は、値が７未満の文字数を包括するものに強制されている。従って、次の命令文（ｓｔａｔｅｍｅｎｔ）が、この型定義に対して真であることが言える。
“Ｔｅｒｓｅ”ｉｎ ＳｍａｌｌＴｅｘｔ
！（“Ｖｅｒｂｏｓｅ”ｉｎ ＳｍａｌｌＴｅｘｔ）

型宣言は、次の式からなる。
ｔｙｐｅ ＴｉｎｙＴｅｘｔ：ＳｍａｌｌＴｅｘｔ ｗｈｅｒｅ ｖａｌｕｅ．Ｃｏｕｎｔ＜６；

しかし、この例において、この宣言は次の式と等価である。
ｔｙｐｅ ＴｉｎｙＴｅｘｔ：Ｔｅｘｔ ｗｈｅｒｅ ｖａｌｕｅ．Ｃｏｕｎｔ＜６；

型の名前が存在し、それによりＤ宣言または式がそれに言及できることに留意されたい。名前は幾つでも、同一の型（例えば、Ｔｅｘｔ ｗｈｅｒｅ ｖａｌｕｅ．Ｃｏｕｎｔ＜７）に割当てることができ、所与の値が名前の全てに適合するか、名前に全く適合しないかのどちらかである。例えば、次の例が考えられる、
ｔｙｐｅ Ａ：Ｎｕｍｂｅｒ ｗｈｅｒｅ ｖａｌｕｅ＜１００；
ｔｙｐｅ Ｂ：Ｎｕｍｂｅｒ ｗｈｅｒｅ ｖａｌｕｅ＜１００：

これら２つの型定義が与えられると、次の両式
ｌ ｉｎ Ａ
ｌ ｉｎ Ｂ
が、真となるであろう。次の第３の型が導入されると、
ｔｙｐｅ Ｃ：Ｎｕｍｂｅｒ ｗｈｅｒｅ ｖａｌｕｅ＞０；
以下が記述できる。
１ ｉｎ Ｃ

Ｄの一般的原理は、所与の値が任意の数の型に適合できることである。このことは、値が起動時に特定の型に固定され、型が定義されたとき指定された有限集合である下位の型のメンバである多くのオブジェクトベースのシステムが稼働する方式からの逸脱である。

議論を生む別の型に関連する運用は、型帰属オペレータ（ｔｙｐｅ ａｓｃｒｉｐｔｉｏｎ ｏｐｅｒａｔｏｒ）（：）である。型帰属オペレータは、所与の値が特定の型に適合していることをアサートする。

一般的には、式中に値が見られるとき、Ｄは、適用されているオペレータ／関数に対して、宣言された結果の型に基づいてその値の予想される型にある考えを有する。例えば、論理およびオペレータ（＆＆）の結果が、型「Ｌｏｇｉｃａｌ」に適合するよう宣言される。

追加的制約を所与の値に適用することは、典型的には、異なる要求項目を有する別のコンテキストの値を使用するために、ときには有用（または、要求されることも）である。例えば、以下の型定義を考えてみる。
ｔｙｐｅ ＳｕｐｅｒＰｏｓｉｔｉｖｅ：Ｎｕｍｂｅｒ ｗｈｅｒｅ ｖａｌｕｅ＞５；

オペランドとして型「ＳｕｐｅｒＰｏｓｉｔｉｖｅ」の値を受け入れるよう宣言される「ＣａｌｃＩｔ」と名付けた関数があると仮定して、Ｄではこのような式を可能にすることが望ましい。すなわち、
ＣａｌｃＩｔ（２０）
ＣａｌｃＩｔ（４２＋９９）
および、このような式を禁じる、すなわち、
ＣａｌｃＩｔ（−１）
ＣａｌｃＩｔ（４）

事実、Ｄはこれら４つの例に対して、必要とされることを正確に行う。なぜなら、これら式が定数上の組み込みオペレータの表現であり、オペランドを表すためである。式の有効性を決定するために必要とされる情報の全ては、式に対してＤソーステキストが出会った瞬間に、無駄なくすぐに利用可能となる。

しかし、式がデータおよび／またはユーザ定義の関数の動的なソースを作成する場合、所与の型に適合するであろうことをアサートするのに型帰属オペレータを使用する。

どのように型帰属オペレータが値を扱うのか理解するため、第２の関数「ＧｅｔＶｏｗｅｌＣｏｕｎｔ」が、型「Ｔｅｘｔ」のオペランドを受け入れ、オペランドの母音の数を指示する型「Ｎｕｍｂｅｒ」の値を返すよう、宣言することを仮定する。

「ＧｅｔＶｏｗｅｌＣｏｕｎｔ」の宣言に基づいたとき、その結果が５より大になるかは未知なので、その点で、次の式は適法なＤ式ではない。
ＣａｌｃＩｔ（ＧｅｔＶｏｗｅｌＣｏｕｎｔ（ｓｏｍｅＴｅｘｔＶａｒｉａｂｌｅ））

この式が適法ではないのは、「ＧｅｔＶｏｗｅｌＣｏｕｎｔ」の宣言した結果の型（Ｎｕｍｂｅｒ）が、「ＣａｌｃＩｔ」（ＳｕｐｅｒＰｏｓｉｔｉｖｅ）の宣言したオペランド型に適合しない値を含んでいるためである。この式は、誤って書かれてあると推定できる。

しかし、この式は、型帰属オペレータを使用して、次の（適法な）式に書き直すことが可能である。すなわち、
ＣａｌｃＩｔ（（ＧｅｔＶｏｗｅｌＣｏｕｎｔ（ｓｏｍｅＴｅｘｔＶａｒｉａｂｌｅ） ： ＳｕｐｅｒＰｏｓｉｔｉｖｅ））

この式により、Ｄには、型「ＳｕｐｅｒＰｏｓｉｔｉｖｅ」に適合する値が取得されるであろうことを知るための「ＧｅｔＶｏｗｅｌＣｏｕｎｔ」関数について十分に理解があることが通知される。簡潔に述べると、プログラマは、Ｄがしていることを彼／彼女が知っていることをＤに通知している。

しかし、プログラマが知らない場合、例えば、プログラマが「ＧｅｔＶｏｗｅｌＣｏｕｎｔ」関数がどのように作動しているか判断ミスをした場合、特別な評価が、結果として負の数字となる可能性がある。「ＣａｌｃＩｔ」関数は、「ＳｕｐｅｒＰｏｓｉｔｉｖｅ」に適合する値を受け入れるためにのみ宣言されたため、システムは、そこを通過した全ての値は５より大であることを確信するであろう。この制約が侵害されないことを確実にするため、システムは、評価されるとき、不合格の可能性を有する動的な制約判定の投入が可能である。この不合格は、Ｄソーステキストが最初に処理されるとき（ＣａｌｃＩｔ（−１）と同様に）に起きるのではなく、不合格は式が実際に評価されるときに起きる。

この点に関して、典型的には、Ｄの実装は、Ｄドキュメントの最初の式が評価される前に、如何なる制約違反も連絡するよう試行する。これは静的エンフォースメントと称せられ、また実装は構文規則エラーに酷似していることを明示する。しかし、幾つかの制約は、生のデータに対してのみ強制できるので、したがって動的エンフォースメントを必要とする。

この点で、Ｄによって、ユーザがユーザの意図することを書き込み易くなり、「上手くいくようにする（ｍａｋｅ ｉｔ ｗｏｒｋ）」ためＤの実装に負担が掛かる。随意に、広範囲な環境に特定のＤドキュメントを使用可能にするため、Ｄ実装の全機能は、動的な制約違反の実行および運用の負担を低減するために、正確さに対して動的エンフォースメントに依存するＤドキュメントを拒否するように設定することが可能である。

さらなる背景の観点から、Ｄである型コンストラクタ（ｃｏｎｓｔｒｕｃｔｏｒ）は、コレクション型を特定するように定義できる。コレクション型コンストラクタは、コレクションが含む型および要素の数を制限する。全てのコレクション型は、基本型（ｉｎｔｒｉｎｓｉｃ ｔｙｐｅ）「Ｃｏｌｌｅｃｔｉｏｎ」上の制約項であり、例えば、全てのコレクション値は次の式に準ずる。
｛｝ｉｎ Ｃｏｌｌｅｃｔｉｏｎ
｛１，ｆａｌｓｅ｝ｉｎ Ｃｏｌｌｅｃｔｉｏｎ
！（“Ｈｅｌｌｏ”ｉｎ Ｃｏｌｌｅｃｔｉｏｎ）

最後の例として、コレクション型は単純型に重複しないことを実際に示す。コレクション型および単純型の両方に適合する値はない。

コレクション型コンストラクタは、要素の型および受入れ可能な要素数の両方を特定する。要素数は、典型的には３つのオペレータの１つを用いて特定する。
Ｔ^* ０以上のＴ
Ｔ＋ １以上のＴ
Ｔ＃ｍ．．ｎ ｍとｎとの間のＴ

コレクション型コンストラクタは、制約として、Ｋｌｅｅｎｅオペレータの使用または基本型Ｃｏｌｌｅｃｔｉｏｎ上の非簡略記述（ｌｏｎｇｈａｎｄ）のどちらかでできる。すなわち、次の型宣言は同一のコレクション値の集合を表す。
ｔｙｐｅ ＳｏｍｅＮｕｍｂｅｒｓ：Ｎｕｍｂｅｒ＋；
ｔｙｐｅ ＴｗｏＴｏＦｏｕｒＮｕｍｂｅｒｓ：Ｎｕｍｂｅｒ＃２．．４；
ｔｙｐｅ ＴｈｒｅｅＮｕｍｂｅｒｓ：Ｎｕｍｂｅｒ＃３；
ｔｙｐｅ ＦｏｕｒＯｒＭｏｒｅＮｕｍｂｅｒｓ：Ｎｕｍｂｅｒ＃４．．；

これらの型は、これら非簡略記述定義型として、同一の値の集合を表す。
ｔｙｐｅ ＳｏｍｅＮｕｍｂｅｒｓ：Ｃｏｌｌｅｃｔｉｏｎ ｗｈｅｒｅ ｖａｌｕｅ．Ｃｏｕｎｔ＞＝１
＆＆ｉｔｅｍ ｉｎ Ｎｕｍｂｅｒ；
ｔｙｐｅ ＴｗｏＴｏＮｕｍｂｅｒｓ：Ｃｏｌｌｅｃｔｉｏｎ ｗｈｅｒｅ ｖａｌｕｅ．Ｃｏｕｎｔ＞＝２
＆＆ｖａｌｕｅ．Ｃｏｕｎｔ＜＝４
＆＆ｉｔｅｍ ｉｎ Ｎｕｍｂｅｒ；
ｔｙｐｅ ＴｈｒｅｅＮｕｍｂｅｒｓ：Ｃｏｌｌｅｃｔｉｏｎ ｗｈｅｒｅ ｖａｌｕｅ．Ｃｏｕｎｔ＝＝３
＆＆ｉｔｅｍ ｉｎ Ｎｕｍｂｅｒ；
ｔｙｐｅ ＦｏｕｒＯｒＭｏｒｅＮｕｍｂｅｒｓ：Ｃｏｌｌｅｃｔｉｏｎ ｗｈｅｒｅ ｖａｌｕｅ．Ｃｏｕｎｔ＞＝４
＆＆ｉｔｅｍ ｉｎ Ｎｕｍｂｅｒ；

型宣言に使用される形式とは無関係に、次の式が記載できる。
！（｛ ｝ｉｎ ＴｗｏＴｏＦｏｕｒＮｕｍｂｅｒｓ）
！（｛“Ｏｎｅ”，“Ｔｗｏ”，“Ｔｈｒｅｅ”｝ｉｎ ＴｗｏＴｏＦｏｕｒＮｕｍｂｅｒｓ）
｛１，２，３｝ｉｎ ＴｗｏＴｏＦｏｕｒＮｕｍｂｅｒｓ
｛１，２，３｝ｉｎ ＴｈｒｅｅＮｕｍｂｅｒｓ
｛１，２，３，４，５｝ｉｎ ＦｏｕｒＯｒＭｏｒｅＮｕｍｂｅｒｓ

コレクション型コンストラクタは「ｗｈｅｒｅ」オペレータを伴って構成され、次の型チェックの結果を得ることを可能にする。
｛１，２｝ｉｎ （Ｎｕｍｂｅｒ ｗｈｅｒｅ ｖａｌｕｅ＜３）＊ｗｈｅｒｅ ｖａｌｕｅ．Ｃｏｕｎｔ％２＝＝０
括弧内「ｗｈｅｒｅ」オペレータはコレクションの要素に適用され、括弧外の「ｗｈｅｒｅ」オペレータはコレクション自体に適用されることに留意されたい。

所与のコンテキストで有効であるコレクションの種類を指定するのにコレクション型コンストラクタを使用できるのと同様に、エンティティ型を使用してエンティティに対して同じことができる。

この点に関して、エンティティ型は、エンティティ値の集合の予測されるメンバを宣言する。エンティティ型のメンバは、フィールドまたは計算値のどちらかで宣言可能である。フィールドの値が格納され、計算値の値が算出される。Ｅｎｔｉｔｙ型は、Ｅｎｔｉｔｙ型上の制約項であり、Ｄ標準ライブラリで定義される。

次の宣言は、単純エンティティ型である。
ｔｙｐｅ ＭｙＥｎｔｉｔｙ：Ｌａｎｇｕａｇｅ．Ｅｎｔｉｔｙ；

「ＭｙＥｎｔｉｔｙ」型はどのフィールドも宣言しない。Ｄにおいて、エンティティ型は、型に適合するエンティティ値が、名前が型で宣言されないフィールドを含む点で、オープンである。このように、次の型判別、
｛Ｘ＝１００，Ｙ＝２００｝ ｉｎ ＭｙＥｎｔｉｔｙ
は、「ＭｙＥｎｔｉｔｙ」型が、ＸとＹとに名前を付けられたフィールドについては何も言及していないので真として評価する。

エンティティ型は、１つ以上のフィールド宣言を含むことができる。最低限、フィールド宣言は予想フィールドの名前を記述する、例えば、
ｔｙｐｅ Ｐｏｉｎｔ｛Ｘ；Ｙ；｝

この型定義は、少なくともＸおよびＹと名付けられたフィールドを、それらフィールドの値に関係なく含むエンティティの集合を記述し、その型定義は次の型判別が真（ｔｒｕｅ）であることを意味する。
｛Ｘ＝１００，Ｙ＝２００｝ｉｎ Ｐｏｉｎｔ
｛Ｘ＝１００，Ｙ＝２００，Ｚ＝３００｝ｉｎ Ｐｏｉｎｔ ／／予想以上のフィールドに対して−ＯＫ
！（｛Ｘ＝１００｝ｉｎ Ｐｏｉｎｔ） ／／フィールドが十分ではない−ＯＫではない
｛Ｘ＝ｔｒｕｅ， Ｙ＝“Ｈｅｌｌｏ，ｗｏｒｌｄ”｝ｉｎ Ｐｏｉｎｔ

最後の例として、「Ｐｏｉｎｔ」型がＸおよびＹフィールドの値を制約しないことを実際に示す、すなわち、任意の値が可能となる。数値に対してＸおよびＹの値を制約する新規の型が次のように説明される。
ｔｙｐｅ ＮｕｍｅｒｉｃＰｏｉｎｔ｛
Ｘ：Ｎｕｍｂｅｒ；
Ｙ：Ｎｕｍｂｅｒ ｗｈｅｒｅ ｖａｌｕｅ＞０
｝

型帰属構文規則を使用し、ＸおよびＹフィールドの値が型「Ｎｕｍｂｅｒ」に適合すべきことをアサートできることに留意されたい。適切にこれを踏まえ、次の式は真である。すなわち、
｛Ｘ＝１００，Ｙ＝２００｝ｉｎ ＮｕｍｅｒｉｃＰｏｉｎｔ
｛Ｘ＝１００，Ｙ＝２００，Ｚ＝３００｝ｉｎ ＮｕｍｅｒｉｃＰｏｉｎｔ
！（｛Ｘ＝ｔｒｕｅ，Ｙ＝“Ｈｅｌｌｏ，ｗｏｒｌｄ”｝ｉｎ ＮｕｍｅｒｉｃＰｏｉｎｔ）
！（｛Ｘ＝０，Ｙ＝０｝ｉｎ ＮｕｍｅｒｉｃＰｏｉｎｔ）

単純型の議論でわかったように、Ｄ宣言および式は型を参照できるように型の名前が存在する。そのことが、ＮｕｍｅｒｉｃＰｏｉｎｔおよびＰｏｉｎｔの定義が独立しているとしても、次の両型判別の成立する理由である。
｛Ｘ＝１００，Ｙ＝２００｝ｉｎ ＮｕｍｅｒｉｃＰｏｉｎｔ
｛Ｘ＝１００，Ｙ＝２００｝ｉｎ Ｐｏｉｎｔ

Ｄのフィールドは値を保持するストレージのユニットと称される。Ｄにより、エンティティ初期化子の一部として、開発者はフィールドの値を初期化できる。しかし、Ｄは、一旦初期化されると、フィールドの値を変更するための如何なるメカニズムも、特定しない。Ｄにおいて、フィールドの値に対する任意の変更が、Ｄのスコープ（適用範囲）外で生ずる場合を仮定する。

フィールド宣言は、フィールドに対して、デフォルト値があることを示すことができる。デフォルト値を有するフィールド宣言は、対応するフィールドが特定されるよう適合エンティティに要求しない（上記フィールド宣言は、オプショナルフィールドと呼ばれることがある）。例えば、次の型定義に関しては、
ｔｙｐｅ Ｐｏｉｎｔ３ｄ｛
Ｘ：Ｎｕｍｂｅｒ；
Ｙ：Ｎｕｍｂｅｒ；
Ｚ＝−１：Ｎｕｍｂｅｒ； ／／負のデフォルト値
}
Ｚフィールドはデフォルト値を有しているので、次の型判別が成立する。
｛Ｘ＝１００，Ｙ＝２００｝ｉｎ Ｐｏｉｎｔ３ｄ

さらに、型帰属オペレータが値に次のように適用される場合、
（｛Ｘ＝１００，Ｙ＝２００｝：Ｐｏｉｎｔ３ｄ）
Ｚフィールドは、次のようにアクセス可能である。
（｛Ｘ＝１００，Ｙ＝２００｝：Ｐｏｉｎｔ３ｄ）．Ｚ
この場合、この式は値−１となる。

別の非限定態様において、フィールド宣言が対応するデフォルト値をもたない場合、適合するエンティティは、そのフィールドに対して、値を特定する必要がある。デフォルト値は、典型的には「Ｐｏｉｎｔ３ｄ」のＺフィールドに対して示す明示的構文規則を使用して書かれる。フィールドの型が、ヌルである可能性のある、またはゼロから多数であるコレクションの何れかの場合、オプショナルに対してヌルの宣言フィールドおよびコレクションに対して｛｝の宣言フィールドのための暗黙的デフォルト値がある。

例えば、次の型を考えてみる。
ｔｙｐｅ ＰｏｉｎｔＮＤ｛
Ｘ：Ｎｕｍｂｅｒ；
Ｙ：Ｎｕｍｂｅｒ；
Ｚ：Ｎｕｍｂｅｒ？； ／／Ｚはオプショナル
ＢｅｙｏｎｄＺ：Ｎｕｍｂｅｒ^*； ／／ＢｅｙｏｎｄＺもオプショナルである。
｝

次に、再度、次の型判別が成立する。
｛Ｘ＝１００，Ｙ＝２００｝ｉｎ ＰｏｉｎｔＮＤ
および、「ＰｏｉｎｔＮＤ」はその値に対して帰属することにより、これらのデフォルトを生成する。
（｛Ｘ＝１００，Ｙ＝２００｝：ＰｏｉｎｔＮＤ）．Ｚ＝＝ｎｕｌｌ
（｛Ｘ＝１００，Ｙ＝２００｝：ＰｏｉｎｔＮＤ）．ＢｅｙｏｎｄＺ＝＝｛｝

モデル・オプショナル・フィールドに対して、ゼロから１コレクションまたはヌル可能型の使用と、明示的デフォルト値の使用との選択は、一般的には１つのスタイルに帰着する。

計算値は、式と称し、その値は格納よりむしろ計算される。そのような計算値を宣言する型の例は、すなわち、
ｔｙｐｅ ＰｏｉｎｔＰｌｕｓ｛
Ｘ：Ｎｕｍｂｅｒ；
Ｙ：Ｎｕｍｂｅｒ；
／／計算値
ＩｓＨｉｇｈ（）：Ｌｏｇｉｃａｌ｛Ｙ＞０；｝
｝
セミコロンで終わるフィールド宣言とは異なり、計算値宣言は、波括弧により囲まれる式で終了することに留意されたい。

フィールド宣言のように、計算値宣言は、この例のように型帰属を省略できる。
ｔｙｐｅ ＰｏｉｎｔＰｌｕｓ｛
Ｘ：Ｎｕｍｂｅｒ；
Ｙ：Ｎｕｍｂｅｒ；
／／型帰属なしの計算値
ＩｎＭａｇｉｃＱｕａｄｒａｎｔ（）｛ＩｓＨｉｇｈ ＆＆ Ｘ＞０；｝
ＩｓＨｉｇｈ（）：Ｌｏｇｉｃａｌ｛Ｙ＞０；｝
｝

別の非限定態様において、計算値に対して明示的に帰属する値がないとき、Ｄは、自動的に基礎式の宣言された結果の型を基本に、型を推論できる。この例において、式で使用される論理およびオペレータは、「Ｌｏｇｉｃａｌ（論理）」を返すように宣言されていたため、「ＩｎＭａｇｉｃＱｕａｄｒａｎｔ」計算値が、また「Ｌｏｇｉｃａｌ」値を生成すると考える。

上記で定義され、使用された２つの計算値は、エンティティの値自体ではない、それらの結果を計算するための任意な追加情報を要求しなかった。計算値は、式中の計算値を使用するとき、実際の値を特定する必要がある名前を付けたパラメータのリストを随意に宣言できる。下記の式は、パラメータを要求する計算値の例である。
ｔｙｐｅ ＰｏｉｎｔＰｌｕｓ｛
Ｘ：Ｎｕｍｂｅｒ；
Ｙ：Ｎｕｍｂｅｒ；
／／パラメータを要求する計算値
ＷｉｔｈｉｎＢｏｕｎｄｓ（ｒａｄｉｕｓ：Ｎｕｍｂｅｒ）：Ｌｏｇｉｃａｌ｛
Ｘ＊Ｘ＋Ｙ＊Ｙ＜＝ｒａｄｉｕｓ＊ｒａｄｉｕｓ；
｝
ＩｎＭａｇｉｃＱｕａｄｒａｎｔ（）｛ＩｓＨｉｇｈ ＆＆ Ｘ＞０；｝
ＩｓＨｉｇｈ（）：Ｌｏｇｉｃａｌ｛Ｙ＞０；｝
｝

式中この計算値を使用するため、次のように２つのパラメータに値を与える。
（｛Ｘ＝１００，Ｙ＝２００｝：ＰｏｉｎｔＰｌｕｓ）．ＷｉｔｈｉｎＢｏｕｎｄｓ（５０）

「ＷｉｔｈｉｎＢｏｕｎｄｓ」の値を計算すると、Ｄは記号ラジウス（ｒａｄｉｕｓ）に値５０を結び付け、それにより「ＷｉｔｈｉｎＢｏｕｎｄｓ」計算値が偽となる。

フィールドに対する計算値およびデフォルト値の両値は、型に適合する値の一部でなく、型定義の一部であることに、Ｄに関連して留意されたい。例えば、これら３つの型定義を考えると、
ｔｙｐｅ Ｐｏｉｎｔ｛
Ｘ：Ｎｕｍｂｅｒ；
Ｙ：Ｎｕｍｂｅｒ；
｝
ｔｙｐｅ ＲｉｃｈＰｏｉｎｔ｛
Ｘ：Ｎｕｍｂｅｒ；
Ｙ：Ｎｕｍｂｅｒ；
Ｚ＝−１：Ｎｕｍｂｅｒ；
ＩｓＨｉｇｈ（）：Ｌｏｇｉｃａｌ｛Ｘ＜Ｙ；｝
}
ｔｙｐｅ ＷｅｉｒｄＰｏｉｎｔ｛
Ｘ：Ｎｕｍｂｅｒ；
Ｙ：Ｎｕｍｂｅｒ；
Ｚ＝４２：Ｎｕｍｂｅｒ；
ＩｓＨｉｇｈ（）：Ｌｏｇｉｃａｌ｛ｆａｌｓｅ；｝
}

ＲｉｃｈＰｏｉｎｔおよびＷｅｉｒｄＰｏｉｎｔのみ、２つの要求されたフィールド（ＸおよびＹ）を有するので、以下の式が記述できる。

｛Ｘ＝１，Ｙ＝２｝ｉｎ ＲｉｃｈＰｏｉｎｔ
｛Ｘ＝１，Ｙ＝２｝ｉｎ ＷｅｉｒｄＰｏｉｎｔ

しかし、「ＩｓＨｉｇｈ」計算値は、これら２つの型内の１つがエンティティ値に帰属するときにのみ利用可能である。すなわち、
（｛Ｘ＝１，Ｙ＝２｝：ＲｉｃｈＰｏｉｎｔ）．ＩｓＨｉｇｈ＝＝ｔｒｕｅ
（｛Ｘ＝１，Ｙ＝２｝：ＷｅｉｒｄＰｏｉｎｔ） ．ＩｓＨｉｇｈ＝＝ｆａｌｓｅ

計算値は、完全に型の一部であり、値ではないため、帰属が連鎖されるとき、次の式のようになり、
（（｛Ｘ＝１，Ｙ＝２｝：ＲｉｃｈＰｏｉｎｔ）：ＷｅｉｒｄＰｏｉｎｔ）．ＩｓＨｉｇｈ＝＝ｆａｌｓｅ
次に、最外部の帰属が呼び出される関数を決定する。

同様の原理が、デフォルト値がどのように動作するかに対して働いている。デフォルト値は、エンティティ値ではなく、型の一部であることに再度留意されたい。従って、次の式が書かれると、
（｛Ｘ＝１，Ｙ＝２｝：ＲｉｃｈＰｏｉｎｔ）．Ｚ＝＝−１
基礎エンティティ値は、まだ、２つのフィールド値（ＸおよびＹに対して、夫々１および２）を含むだけである。この点に関して、デフォルト値は計算値と異なっており、帰属が連鎖している。例えば、次の式を考えてみる。
（（｛Ｘ＝１，Ｙ＝２｝：ＲｉｃｈＰｏｉｎｔ）：ＷｅｉｒｄＰｏｉｎｔ）．Ｚ＝＝−１
「ＲｉｃｈＰｏｉｎｔ」帰属を最初に適用するので、結果として得たエンティティは、−１の値を有するＺと名付けられたフィールドを持つが、その値に割当てられたストレージはなく、すなわち、値に関する型の解釈の１部である。従って、「ＷｅｉｒｄＰｏｉｎｔ」帰属が適用されるとき、Ｚと名付けられたフィールドを有する一番目の帰属の結果に適用され、結果として、Ｚに対して値を特定するために値を使用する。このように、「ＷｅｉｒｄＰｏｉｎｔ」が特定したデフォルト値は必要とはされない。

全ての型と同様に、制約は、「ｗｈｅｒｅ」オペレータを使用して、エンティティ型に適用可能である。次のＤ型定義を考えてみると、
ｔｙｐｅ ＨｉｇｈＰｏｉｎｔ｛
Ｘ：Ｎｕｍｂｅｒ；
Ｙ：Ｎｕｍｂｅｒ；
｝ｗｈｅｒｅ Ｘ＜Ｙ；

この例において、型「ＨｉｇｈＰｏｉｎｔ」に適合する全ての値は、Ｙ値未満のＸ値を有することを保証される。そのことは、次の式を意味する。
｛Ｘ＝１００，Ｙ＝２００｝ｉｎ ＨｉｇｈＰｏｉｎｔ
！（｛Ｘ＝３００，Ｙ＝２００｝ｉｎ ＨｉｇｈＰｏｉｎｔ）
両式は真である。

さらに、次の型定義に関して、
ｔｙｐｅ Ｐｏｉｎｔ｛
Ｘ：Ｎｕｍｂｅｒ；
Ｙ：Ｎｕｍｂｅｒ；
｝
ｔｙｐｅ Ｖｉｓｕａｌ｛
Ｏｐａｃｉｔｙ：Ｎｕｍｂｅｒ；
｝
ｔｙｐｅ ＶｉｓｕａｌＰｏｉｎｔ｛
ＤｏｔＳｉｚｅ：Ｎｕｍｂｅｒ；
｝ｗｈｅｒｅ ｖａｌｕｅ ｉｎ Ｐｏｉｎｔ ＆＆ ｖａｌｕｅ ｉｎ Ｖｉｓｕａｌ；
第３の型、「ＶｉｓｕａｌＰｏｉｎｔ」は、少なくとも数値フィールドＸ、Ｙ、Ｏｐａｃｉｔｙ、およびＤｏｔｓｉｚｅを有するエンティティ値の集合を指定する。

一般的に、メンバ宣言を、組立て可能な小さな項目に分解することが望まれるため、Ｄは、また分解を支援する明示的構文規則を提供する。事例として、「ＶｉｓｕａｌＰｏｉｎｔ」型定義は、その構文規則を使用して書き直すことができる。
ｔｙｐｅ ＶｉｓｕａｌＰｏｉｎｔ：Ｐｏｉｎｔ，Ｖｉｓｕａｌ｛
ＤｏｔＳｉｚｅ：Ｎｕｍｂｅｒ；
｝

明確に言えば、これは制約式を使用した上記非簡略記述（ｌｏｎｇ−ｈａｎｄ）定義に対する簡略記述（ｓｈｏｒｔｈａｎｄ）である。さらに、この簡略記述定義および非簡略記述定義の両方とも、より長い非簡略記述（ｌｏｎｇｅｒ−ｈａｎｄ）定義とも等価となる。
ｔｙｐｅ ＶｉｓｕａｌＰｏｉｎｔ＝｛
Ｘ：Ｎｕｍｂｅｒ；
Ｙ：Ｎｕｍｂｅｒ；
Ｏｐａｃｉｔｙ：Ｎｕｍｂｅｒ；
ＤｏｔＳｉｚｅ：Ｎｕｍｂｅｒ；
｝

再度、型の名称は型を参照するための単なる手段である。値自体は、値を記述するのに使用される型名の記録を全く有していない。

Ｄは、また簡単なクエリの作成をより簡潔にする数個の機能で、ＬＩＮＱクエリの取り扱い能力を拡張できる。キーワードである、「ｗｈｅｒｅ」および「ｓｅｌｅｃｔ」は、バイナリ中置オペレータ（ｉｎｆｉｘ ｏｐｅｒａｔｏｒ）として利用できる。また、インデクサ（ｉｎｄｅｘｅｒ）は、強力に型付けしたコレクションに自動的に追加される。これら機能により、一般のクエリを下記に説明するように、よりコンパクトに作成できる。

中置オペレータの例として、次のクエリは「Ｐｅｏｐｌｅ」の定義されたコレクションから３０歳未満の人を抽出する。
ｆｒｏｍ ｐ ｉｎ Ｐｅｏｐｌｅ
ｗｈｅｒｅ ｐ．Ａｇｅ＝３０
ｓｅｌｅｃｔ ｐ

同等のクエリを書くことができる。すなわち、
Ｐｅｏｐｌｅ ｗｈｅｒｅ ｖａｌｕｅ．Ａｇｅ＝３０

「ｗｈｅｒｅ」オペレータは、左側でコレクションを取り、右側ではブール式を取る。「ｗｈｅｒｅ」オペレータは、コレクションの各メンバが拘束されるブール式のスコープにキーワード識別子の値を挿入する。結果として得られるコレクションは、式が真であるメンバを含む。従って、次式
Ｃｏｌｌｅｃｔｉｏｎ ｗｈｅｒｅ Ｅｘｐｒｅｓｓｉｏｎ
は、以下の式と等価である。
ｆｒｏｍ ｖａｌｕｅ ｉｎ Ｃｏｌｌｅｃｔｉｏｎ
ｗｈｅｒｅ Ｅｘｐｒｅｓｓｉｏｎ
ｓｅｌｅｃｔ ｖａｌｕｅ

Ｄコンパイラは、インデクサ・メンバを、強力に型付けした要素と共にコレクションに追加する。コレクション「Ｐｅｏｐｌｅ」に対して、事例として、コンパイラは、インデクサを「Ｆｉｒｓｔ（Ｔｅｘｔ）」、「Ｌａｓｔ（Ｔｅｘｔ）」、および「Ａｇｅ（Ｎｕｍｂｅｒ）」に対して追加できる。

従って、以下の文の、
Ｃｏｌｌｅｃｔｉｏｎ．Ｆｉｅｌｄ（Ｅｘｐｒｅｓｓｉｏｎ）
は、以下の式と等価である。
ｆｒｏｍ ｖａｌｕｅ ｉｎ Ｃｏｌｌｅｃｔｉｏｎ
ｗｈｅｒｅ Ｆｉｅｌｄ＝＝Ｅｘｐｒｅｓｓｉｏｎ
ｓｅｌｅｃｔ ｖａｌｕｅ

「Ｓｅｌｅｃｔ」は、また中置きオペレータとして使用可能である。次の簡単なクエリに関して、
ｆｒｏｍ ｐ ｉｎ Ｐｅｏｐｌｅ
ｓｅｌｅｃｔ ｐ．Ｆｉｒｓｔ＋ｐ．Ｌａｓｔ
式「ｓｅｌｅｃｔ」は、コレクションの各メンバ上で算出され、その結果を返す。

中置き「ｓｅｌｅｃｔ」を使用し、クエリを下記のように等価に書くことができる。

Ｐｅｏｐｌｅ ｓｅｌｅｃｔ ｖａｌｕｅ．Ｆｉｒｓｔ＋ｖａｌｕｅ．Ｌａｓｔ

「ｓｅｌｅｃｔ」オペレータは、左側でコレクションをとり、右側で任意の式をとる。「ｗｈｅｒｅ」について、「ｓｅｌｅｃｔ」は、コレクションの各要素にわたり、キーワード識別子値を導入する。「ｓｅｌｅｃｔ」オペレータは、コレクションの各要素にわたり式をマッピングし、その結果を返す。他の例に対して、以下の文の、
Ｃｏｌｌｅｃｔｉｏｎ ｓｅｌｅｃｔ Ｅｘｐｒｅｓｓｉｏｎ
は、以下の式と等価である。
ｆｒｏｍ ｖａｌｕｅ ｉｎ Ｃｏｌｌｅｃｔｉｏｎ
ｓｅｌｅｃｔ Ｅｘｐｒｅｓｓｉｏｎ

「ｓｅｌｅｃｔ」オペレータの通常の使用は、単一のフィールドを抽出することである。
Ｐｅｏｐｌｅ ｓｅｌｅｃｔ ｖａｌｕｅ．Ｆｉｒｓｔ
コンパイラは、アクセサ（ａｃｃｅｓｓｏｒｓ）をコレクションに追加し、それにより単一フィールドは、「Ｐｅｏｐｌｅ．Ｆｉｒｓｔ」および「Ｐｅｏｐｌｅ．Ｌａｓｔ」として直接抽出できる。

正式なＤドキュメントを書くために、ソーステキスト全てがモジュール定義のコンテキストに現れる。モジュールは、定義される任意な型の名前に対し、トップレベルの名前空間を定義する。モジュールは、また計算値と同様に実際の値を格納するであろうエクステント（ｅｘｔｅｎｔ）を定義するためにスコープ（適用範囲）を定義する。

以下の式は、モジュール定義の簡単な例である。
ｍｏｄｕｌｅ Ｇｅｏｍｅｔｒｙ｛
／／型を宣言
ｔｙｐｅ Ｐｏｉｎｔ｛
Ｘ：Ｉｎｔｅｇｅｒ；Ｙ：Ｉｎｔｅｇｅｒ；
｝
／／幾つかのエクステントを宣言
Ｐｏｉｎｔ：Ｐｏｉｎｔ^*；
Ｏｒｉｇｉｎ：Ｐｏｉｎｔ；
／／計算値を宣言
ＴｏｔａｌＰｏｉｎｔＣｏｕｎｔ｛Ｐｏｉｎｔｓ．Ｃｏｕｎｔ＋１；｝
｝

この例において、モジュールは、「Ｇｅｏｍｅｔｒｙ．Ｐｏｉｎｔ」と名付けられた１つの型を定義する。この型は、ポイント値はどのようなものかを記述するが、これら値が格納できる場所を全く定義しない。

この例は、また２つのモジュールスコープ化フィールド（ＰｏｉｎｔおよびＯｒｉｇｉｎ）を含む。モジュールスコープ化フィールド宣言は、エンティティ型で使用するこれらに構文規則で一致する。しかし、エンティティ型で宣言されたフィールドは、一旦エクステントが決定されていると、簡単にストレージの可能性を示すが、これと対照的に、モジュールスコープ化で宣言されるフィールドは、モジュールをロードし、解釈するために、実装によりマッピングする必要がある実際のストレージを示す。

さらに、モジュールは、参照される宣言を含むモジュールを指示するインポート指令を用いて、他のモジュールの宣言を参照できる。他のモジュールにより参照されるべき宣言に対し、その宣言は明示的にエクスポート指令を用いてエクスポートできる。

例えば、次のモジュールを考えてみる。
ｍｏｄｕｌｅ ＭｙＭｏｄｕｌｅ｛
ｉｍｐｏｒｔ ＨｅｒＭｏｄｕｌｅ； ／／ＨｅｒＴｙｐｅを宣言
ｅｘｐｏｒｔ ＭｙＴｙｐｅ１；
ｅｘｐｏｒｔ ＭｙＥｘｔｅｎｔ１；
ｔｙｐｅ ＭｙＴｙｐｅ１：Ｌｏｇｉｃａｌ^*；
ｔｙｐｅ ＭｙＴｙｐｅ２：ＨｅｒＴｙｐｅ；
ＭｙＥｘｔｅｎｔ１：Ｎｕｍｂｅｒ^*；
ＭｙＥｘｔｅｎｔ２：ＨｅｒＴｙｐｅ；
｝
他のモジュールは単に「ＭｙＴｙｐｅ１」および「ＭｙＥｘｔｅｎｔ１」だけを見えることに留意されたい。それにより、「ＨｅｒＭｏｄｕｌｅ」の次の定義が正式なものになる。
ｍｏｄｕｌｅ ＨｅｒＭｏｄｕｌｅ｛
ｉｍｐｏｒｔ ＭｙＭｏｄｕｌｅ； ／／ＭｙＴｙｐｅ１およびＭｙＥｘｔｅｎｔ１を宣言
ｅｘｐｏｒｔ ＨｅｒＴｙｐｅ；
ｔｙｐｅ ＨｅｒＴｙｐｅ：Ｔｅｘｔ ｗｈｅｒｅ ｖａｌｕｅ．Ｃｏｕｎｔ＜１００；
ｔｙｐｅ Ｐｒｉｖａｔｅ：Ｎｕｍｂｅｒ ｗｈｅｒｅ！（ｖａｌｕｅ ｉｎ ＭｙＥｘｔｅｎｔ１）；
ＳｏｍｅＳｔｏｒａｇｅ：ＭｙＴｙｐｅ１；
｝
この例で示すように、モジュールは、循環依存性（ｃｉｒｃｕｌａｒ ｄｅｐｅｎｄｅｎｃｙ）を有している。

Ｄ言語の型は、２つの主要区分に分かれる。それは、基本型および派生型（ｄｅｒｉｖｅｄ ｔｙｐｅ）である。基本型はＤ言語構文を使用して定義できない型であるが、他はＤ言語仕様で完全に定義される。基本型は、その仕様の一部である上位型（ｓｕｐｅｒ−ｔｙｐｅ）として、多くても１つの基本型を指定することしかできない。値は、確かに１つの基本型の事例であり、１つの基本型およびその上位型全ての仕様に適合する。

派生型は、言語で提供される型コンストラクタを使用して、定義がＤソーステキストで構築される型である。派生型は、別の型上の制約として定義され、明示的な下位型付け関係を生成する。値は、派生型の制約を満たすことにより、簡単に幾つでも派生型に適合する。値および派生型間では先験的な係属性（ａ ｐｒｉｏｒｉ ａｆｆｉｌｉａｔｉｏｎ）はなく、むしろ派生型の制約に適合する所与の値が、その型として自由に解釈できる。

Ｄは型定義において広範囲の選択を提供する。コレクションを返す任意の式が、型として宣言可能である。エンティティおよびコレクションに対する型述語（ｐｒｅｄｉｃａｔｅ）は、式であり、この書式に適合する。型宣言は、明示的にそのメンバを列挙できるか、または他の型から構成される。

別の異なる点は、Ｄのような構造的に型付けされた言語および名目上の型付け言語との間にある。Ｄの型は、値の集合に対する仕様である。２つの型は、全く同一の値コレクションが、型の名前と関係なく、両型に適合する場合、同一である。型には使用するための名前を付ける必要はない。型の式は、型参照が要求されるどの場所においても可能である。Ｄにある型は、コレクションを返す簡単な式である。

型Ａに適合するどの値もまた型Ｂに適合するなら、ＡはＢの下位型である（そうすると、ＢはＡの上位型である）。下位型付けは、推移的なものであり、すなわち、ＡがＢの下位型であり、ＢがＣの下位型である場合、ＡはＣの下位型である（そうすると、ＣはＡの上位型である）。下位型付けは、再帰的である、すなわち、ＡはＡの（実質のない（ｖａｃｕｏｕｓ））下位型である（そしてＡはＡの上位型である）。

型は、型述語を満足させる全値のコレクションと見なされる。この理由として、コレクションのどの運用も、型に適用でき、また型は他のどのコレクション値のような式でも操作できる。

Ｄは、値が成立するための２つの主なる手段を提供する、すなわち、計算値および格納値（別称、フィールド）である。計算値および格納値は、モジュールおよびエンティティ宣言両方を伴って生じることが可能で、コンテナによりスコープ化される。計算値は、典型的には、Ｄソーステキストの一部として定義される式を評価することから導かれる。対照的に、フィールドは、値を格納し、フィールドのコンテンツは、経時とともに変化する。

例示的ネットワークおよび分散環境
当業者には、本明細書で記述するデータスクリプト言語の型システムに対して、様々な実施形態が、任意のコンピュータまたは他のクライアントもしくはサーバデバイスと接続して実装可能であり、コンピュータネットワーク、または分散型コンピューティング環境の一部として配置可能であり、また任意の種類のデータストアに接続可能であることは理解されよう。この点に関して、本明細書で記述した様々な実施形態は、任意のコンピュータシステムまたは任意の数のメモリもしくは記憶装置を有する環境で、ならびに任意な数のアプリケーションおよび任意な数の記憶装置にわたって生ずるプロセスを実装可能である。これは、サーバコンピュータおよびネットワーク環境で配置されるクライアントコンピュータを有する環境、または、リモートもしくはローカルストレージを有する分散型コンピューティング環境を含むが、これに限定されない。

分散型コンピューティングは、コンピュータリソースの共有ならびにコンピューティングデバイスおよびシステム内の通信交換によるサービスを提供する。これらリソースおよびサービスは、ファイル等の対象物に対して、情報交換、キャッシュストレージ、およびディスクストレージを含む。これらリソースおよびサービスは、また、負荷分散、リソースの拡張、処理の特殊化、等のための複数の処理装置にわたる処理能力の共有も含む。分散型コンピューティングは、ネットワークの接続性を利用して、クライアントが企業全体に利益をもたらすようクライアントの集結能力を押し上げることができる。この点に関して、多様なデバイスが、本主題が開示する様々な実施形態の何れも１つ以上の態様を実行するように協働可能であるアプリケーション、オブジェクトまたはリソースを有することができる。

図１６は、例示的ネットワーク型または分散型コンピューティング環境の概略図を提供するものである。分散型コンピューティング環境は、コンピューティングオブジェクト１６１０、１６１２等、およびコンピューティングオブジェクトまたはデバイス１６２０、１６２２、１６２４、１６２６、１６２８、等から構成され、アプリケーション１６３０、１６３２、１６３４、１６３６、１６３８により表されるようなプログラム、方法、データストア、プログラム可能論理、等を含むことができる。オブジェクト１６１０、１６１２等およびコンピューティングオブジェクトまたはデバイス１６２０、１６２２、１６２４、１６２６、１６２８等は、ＰＤＡ, 音声／映像デバイス、携帯電話、ＭＰ３プレーヤ、パーソナルコンピュータ、ラップトップのような様々なデバイスから構成できることを理解されたい。

各オブジェクト１６１０、１６１２等、およびコンピューティングオブジェクトまたはデバイス、１６２０、１６２２、１６２４、１６２６、１６２８等は、１つ以上の他のオブジェクト１６１０、１６１２等およびコンピューティングオブジェクトまたはデバイス１６２０、１６２２、１６２４、１６２６、１６２８等に、直接的または間接的のいずれかで、通信ネットワーク１６４０経由で通信できる。図１６の単一の要素として説明してあるが、ネットワーク１６４０は、図１６のシステムにサービスを提供する他のコンピューティングオブジェクトおよびコンピューティングデバイスから構成でき、および／または複数の相互接続のネットワーク（図示なし）を表現可能である。各オブジェクト１６１０、１６１２等、または１６２０、１６２２、１６２４、１６２６、１６２８等は、本主題の開示である様々な実施形態に従い提供されたデータスクリプト言語のための型システムと通信、処理、またはその実装に適切な、ＡＰＩ、もしくは他のオブジェクト、ソフトウェア、ファームウェアおよび／もしくはハードウェアを使用可能なアプリケーション１６３０、１６３２、１６３４、１６３６、１６３８のようなアプリケーションを含むこともできる。

分散型コンピューティング環境を支援する多様なシステム、コンポーネント、およびネットワーク構成がある。例えば、コンピューティングシステムは、ローカルネットワークまたは広域分散型ネットワークにより、有線または無線システムにより、相互に接続できる。任意のネットワークインフラストラクチャが、様々な実施形態で記述されたように、データスクリプト言語のための型システムに対し、インシデントを起こす例示的通信に対して使用できるが、現在、多くのネットワークが、広域分散型コンピューティングに対してインフラストラクチャを提供し、また多くの様々なネットワークを包括するインターネットに連結している。

このように、クライアント／サーバ、ピアツーピア、またはハイブリットアーキテクチャのようなネットワークトポロジおよびネットワークインフラストラクチャのホストは、有効に利用可能である。「クライアント」は、クラスまたはグループのメンバであり、このクラスまたはグループは、クライアントと関連しない別のクラスまたはグループのサービスを利用する。クライアントは、プロセスと表現でき、すなわち、別のプログラムまたはプロセスにより提供されるサービスを要求する、概ね命令またはタスクの集合である。クライアントプロセスは、他のプログラムまたはサービス自体に関する如何なる作業詳細を「知る」必要なしに要求サービスを有効に利用する。

クライアント／サーバ・アーキテクチャ、特にネットワークシステムにおいて、クライアントは、通常、別のコンピュータ、例えばサーバが提供する共有ネットワークリソースにアクセスするコンピュータである。図１６の説明において、非限定の例として、コンピュータ１６２０、１６２２、１６２４、１６２６、１６２８等は、クライアントとして想定可能であり、およびコンピュータ１６１０、１６１２、等はサーバとして想定可能であり、サーバ１６１０、１６１２等は、クライアントコンピュータ１６２０、１６２２、１６２４、１６２６、１６２８等からのデータ受信、データの格納、データの処理、クライアントコンピュータ１６２０、１６２２、１６２４、１６２６、１６２８等へのデータの送信のような、データサービスを提供するが、どのコンピュータも、その環境により、クライアント、サーバ、またはその両方として考えられる。これらコンピューティングデバイスのどれもが、１つ以上の実施形態に対して本明細書で記述したように、データスクリプト言語の型システムに関係付けられる処理データ、符号化データ、クエリデータ、または要求サービスもしくはタスクであり得る。

サーバは、典型的にはインターネットまたは無線ネットワークインフラストラクチャのようなリモートまたはローカルネットワークを通してアクセス可能な、リモートコンピュータシステムである。クライアントプロセスが、第１のコンピュータシステムにおいて動作可能で、サーバプロセスが第２のコンピュータシステムにおいて動作可能であり、通信媒体を介して相互に通信を行うことで、それ故に、分散機能性を提供し、および複数のクライアントがサーバの情報収集能力を利用できる。データスクリプト言語の型システムに準じて効果的に利用される任意のソフトウェアオブジェクトは、スタンドアローン、または複数のコンピューティングデバイスもしくはオブジェクトにわたる分散が可能である。

通信ネットワーク／バス１６４０がインターネットであるネットワーク環境において、例えば、サーバ１６１０、１６１２等は、クライアント１６２０、１６２２、１６２４、１６２６、１６２８等が、ＨＴＴＰのような数々の周知の任意のプロトコルを介して通信するＷｅｂサーバが可能である。サーバ１６１０、１６１２等は、分散型コンピューティング環境の特性であるクライアント１６２０、１６２２、１６２４、１６２６、１６２８、等としても機能する。

例示的コンピューティングデバイス
上述したように、本明細書で記述した技術は、任意のデバイスに有利に適用可能であるが、データ集約型アプリケーションに接続するどのような種類のデータにも適応する型を、簡単にかつ柔軟性をもって定義することが望まれる。従って、ハンドヘルド、携帯用、その他のコンピューティングデバイスならびに全種類のコンピューティングオブジェクトが、様々な実施形態に関連して使用すると想定される、すなわち、デバイスがいかなるところでも、迅速かつ効果的に、大量のデータを走査または処理することを意図されていることを理解されたい。従って、図１７の下方に説明される下記の汎用リモートコンピュータは、単なるコンピューティングデバイスの一例である。

必須条件ではないが、実施形態を、オペレーティングシステムを介して、デバイスもしくはオブジェクトに対してサービスを開発者が使用するために、部分的に実装可能であり、および／または本明細書で記述した様々な実施形態の１つ以上の機能的態様を実行するために稼働するアプリケーションソフトウェア内に含むことができる。ソフトウェアは、プログラムモジュールのようなコンピュータ実行命令の一般的コンテキストで記述でき、クライアントワークステーション、サーバまたは他のデバイス等の１つ以上のコンピュータによって実行される。コンピュータシステムは、データ通信のために使用できる多様な設定およびプロトコルを有し、それ故、特別な設定またはプロトコルが限定的であると考慮されるべきでないことを、当業者は理解するであろう。

このように、図１７は、本明細書に記述した本実施形態の１つ以上の態様を実装可能な、適切なコンピューティングシステム環境１７００の例を示している。また、上記を明確にするためであるが、コンピューティングシステム環境１７００は、適切なコンピューティング環境の単なる一例であり、使用または機能性の範囲に関してなんら制限を示唆するよう意図していない。コンピューティング環境１７００は、例示的オペレーティング環境１７００で示した１つのコンポーネントまたはコンポーネントの組合せに依存するとも要求されるとも解釈すべきではない。

図１７を参照して、１つ以上の実施形態を実装するための例示的リモートデバイスは、汎用コンピューティングデバイスを、コンピュータ１７１０の形式で含む。コンピュータ１７１０のコンポーネントは、処理装置１７２０、システムメモリ１７３０、およびシステムメモリを含む様々なシステムコンポーネントを処理装置１７２０に連結するシステムバス１７２２を含むことができるが、限定ではない。

コンピュータ１７１０は、典型的には、多様なコンピュータ可読媒体を含み、コンピュータ１７１０がアクセス可能な任意の有効な媒体であることができる。システムメモリ１７３０は、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）および／またはＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）のような揮発性および／または不揮発性メモリの形式で、コンピュータ記憶媒体を含むことができる。限定ではなく、例として、メモリ１７３０は、またオペレーティングシステム、アプリケーションプログラム、他のプログラムモジュール、およびプログラムデータを含むことができる。

ユーザは、入力デバイス１７４０により、コマンドおよび情報をコンピュータ１７１０に入力できる。モニターまたは他の形式の表示デバイスは、出力インターフェース１７５０のような、インターフェ−スを介してシステムバス１７２２に接続される。モニターに加えて、コンピュータは、出力インターフェース１７５０を介して接続できる、スピーカ
およびプリンタ等の他の周辺出力デバイスを含むこともできる。

コンピュータ１７１０は、リモートコンピュータ１７７０のような１つ以上の他のリモートコンピュータへの論理接続を用いて、ネットワーク型または分散型環境で稼働できる。リモートコンピュータ１７７０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、もしくは他の通常のネットワークノード、または任意の他のリモートメディア消費もしくは伝達デバイスが可能であり、コンピュータ１７１０に関して上述した幾つかの要素または全ての要素を含むことができる。図１７で示した論理接続は、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ＝ローカルエリアネットワーク）またはＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ＝広域ネットワーク）のようなネットワーク１７７２を含むが、他のネットワーク／バスを含むことも可能である。上記ネットワーク環境は、家庭、オフィス、企業規模コンピュータネットワーク、イントラネット、およびインターネットで一般的である。

上記のように、例示的実施形態を様々なコンピューティングデバイスおよびネットワークアーキテクチャと関連して述べてきたが、基本概念は、データ集約型アプリケーションに関連する任意の種類のデータ収納のため簡単かつ柔軟に型を定義することが望ましい、任意のネットワークシステムおよびコンピューティングデバイスまたはシステムに適用することができる。

また、同一または類似の機能性を実装する多数の方式があり、例えば、適宜なＡＰＩ、ツールキット、ドライバコード、オペレーティングシステム、制御、スタンドアローン、またはダウンロード可能ソフトウェアオブジェクト等、であり、これにより、アプリケーションおよびサービスが効率のよい符号化および問合せ技術を使用できるようになる。このように、本明細書の実施形態は、ＡＰＩ（または他のソフトウェアオブジェクト）の見地から、また同様に、データスクリプト言語に対する型システムを提供もしくは有効にするソフトウェアやハードウェアオブジェクトの見地から検討される。このように、本明細書の様々な実施形態が、ソフトウェアによるのと同様、全てハードウェア、部分的にハードウェア、および部分的にソフトウェアの態様を有する。

本明細書で使用される単語「例示的（ｅｘｅｍｐｌａｒｙ）」は、例、事例、または説明として供する意味で使用されている。疑問を回避するために、本明細書で開示される主題は上記例によって限定されない。さらに、「例示的」のように、本明細書で記述した如何なる態様または設計は、他の態様または設計より好適または利点があるようには、必ずしも解釈されないし、また当業者に周知である等価な例示的構造および技術を排除することを意味してもいない。さらに、疑問を回避するために、用語「含む（ｉｎｃｌｕｄｅ）」、「有する（ｈａｓ）」、「包含する（ｃｏｎｔａｉｎ）」および他の類似の語句が「発明を実施するための形態」または「特許請求の範囲」のどちらかで使用される範囲に対して、上記用語は、任意な追加要素または他の要素を排除することなく、開放移行として用語「備える（ｃｏｍｐｒｉｓｉｎｇ）」に類似な様式で包含されることを意図する。

言及してきたように、本明細書で記述した様々な技術は、ハードウェアもしくはソフトウェアに、または適宜、その両方の組合せに関連して実装可能である。本明細書で使用したように、用語「コンポーネント（ｃｏｍｐｏｎｅｎｔ）」、「システム（ｓｙｓｔｅｍ）」、等は、同様に、コンピュータ関連のエンティティ、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェア何れかを指すことを意図している。例えば、コンポーネントは、プロセッサ上で動作するプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータが可能であるが、これに限定されない。説明として、コンピュータ上で動作するアプリケーションおよびコンピュータはコンポーネントが可能である。１つ以上のコンポーネントが、プロセスおよび／または実行スレッドに内在でき、またコンポーネントが、１台のコンピュータ上にローカライズされても、かつ／または複数のコンピュータ間で分散されてもよい。

前記のシステムが、数々のコンポーネント間の相互通信に関して記述されてきた。上記システムおよびコンポーネントは、これらコンポーネントもしくは特定の下位コンポーネント、幾つかの特定コンポーネントもしくは下位コンポーネント、および／または追加コンポーネント、ならびに前述の様々な順列および組合せを含むことが可能であることを理解されたい。下位コンポーネントは、また、親コンポーネント（階層的に）内に含まれるより、むしろ他のコンポーネントに通信可能に連結するコンポーネントとして実装できる。追加的に、１つ以上のコンポーネントが集約した機能性を提供する単一のコンポーネントに組合わさるか、または数個の異なる下位コンポーネントに分割されてもよい、しかも１つ以上の、管理層のような中間層の何れかが、統合された機能性を提供するために、上記下位コンポーネントに通信可能に連結されるように提供できることにも留意すべきである。また、本明細書で記述した任意のコンポーネントは、本明細書で具体的には記述されていない１つ以上の他のコンポーネントと相互に通信可能であるが、一般的に当業者には周知である。

上記の例示的システムを考慮して、記述した主題に従い実装できる方法論は、様々な図のフローチャートを参考することによって、一層理解されるであろう。簡潔な説明として、当該方法論は、一連のブロック図として示し、説明されるが、本特許請求主題は、幾つかのブロックは、本明細書で描き記述したものとは異なった順序および／または他のブロックと同時に生じる可能性があるように、ブロックの並びの順序によって限定されないことが理解されるべきである。順次的でないかまたは分岐されるフローを、フローチャートを介して説明しているが、同一または類似の効果を達成する様々な他の分岐、フロー経路、ブロックの順序を実装できることを理解されたい。さらに、説明された全てのブロックが、下文で記述する方法論を実装するよう要求される訳ではない。

本明細書で記述した様々な実施形態に加え、他の類似の実施形態を使用できる、すなわち本主題から逸脱することなしに、対応する実施形態（複数可）の同一または等価な機能を実行するために、修正および加筆を記述の実施形態（複数可）にできることを理解されたい。さらに、複数の処理チップまたは複数のデバイスが本明細書で記述される１つ以上の機能の実行を共有でき、同様に、ストレージが複数のデバイスにわたって成立できる。従って、本発明は、いかなる単一の実施形態にも限定を加えるものではなく、むしろ添付の特許請求に従う精神および範囲は、幅広く解釈されるべきである。

Claims (10)

1. コンピュータシステムであって、
   宣言コードを含むコンピュータ実行可能命令を備えた少なくとも１つのコンピュータ可読モジュールであって、前記宣言コードは、制約ベースの型リファインメントおよび型メンバシップを支援する型システムを実装する宣言型プログラミングモデルに従い、前記少なくとも１つのコンピュータ可読モジュールは、全ての型を表現するトップ型に対する前記型を形成することにより型を定義する前記型システムのリファインメント型を備えるプログラミング構文を含み、前記プログラミング構文のリファインメント型を定義する式は、型判別式を含み、前記型判別式は、該型判別式内の式を評価して、得られる値が指定した型のメンバであるかを決定する、前記少なくとも１つのコンピュータ可読モジュールと、
   データを含む少なくとも１つのデータストアであって、前記コンピュータ実行可能命令のうちの少なくとも１つにより、前記コンピュータシステムは、前記データのアクセス、修正、フィルタリング、変形、バージョニング、および処理のうちの少なくとも１つを、前記宣言コードのプログラミング構文に基づいて行う、少なくとも１つのデータストアと、
   少なくとも１つの判定に基づきエラーが生じたかを決定するように構成された型チェックモジュールであって、前記少なくとも１つの判定は、少なくとも１つの型に関連した少なくとも１つのコンテキストに基づく、型チェックモジュールと
   を備えることを特徴とするコンピュータシステム。
2. 請求項１に記載のシステムであって、型が値を有し、値が型を有することを特徴とするシステム。
3. 請求項１に記載のシステムであって、前記プログラミング構文が、前記型リファインメント構文で特定した少なくとも２つの型の共通集合の仕様を含むことを特徴とするシステム。
4. 請求項１に記載のシステムであって、前記プログラミング構文が、前記型リファインメント構文で特定した少なくとも２つの型の和集合の仕様を含むことを特徴とするシステム。
5. 請求項１に記載のシステムであって、前記プログラミング構文が、前記型リファインメント構文で特定した少なくとも２つの型の和集合および少なくとも２つの型の共通集合の仕様を含むことを特徴とするシステム。
6. 請求項１に記載のシステムであって、前記プログラミング構文が、有効である全ての型がメンバであるトップ型の仕様を含むことを特徴とするシステム。
7. コンピューティングデバイスの少なくとも１つのプロセッサにより宣言コードを実行する方法であって、
   前記コンピューティングデバイスによる実行のために、型付けシステムに従い特定される宣言プログラムであって、前記型付けシステムが、前記宣言プログラムのプログラミング構文内で、型判別式を含む式に基づくリファインメント、および前記宣言プログラムの有効な全ての値がメンバであるトップ型による型付けを支援し、前記型判別式は、該型判別式内の式を評価して、得られる値が指定した型のメンバであるかを決定する、前記宣言プログラムを受信するステップと、
   型付け規則の集合および前記型付けシステムに関連する判定に従い、前記宣言プログラムで表現される型を型チェックするステップであって、前記判定のうちの少なくとも１つは、少なくとも１つの型に関連した少なくとも１つのコンテキストに基づく、ステップと
   を含む方法。
8. 請求項７に記載の方法であって、前記宣言プログラムを受信するステップは、値を有する型および型を有する値を支援する型付けシステムに従って前記宣言プログラムを受信するステップを含むことを特徴とする方法。
9. 請求項７に記載の方法であって、前記宣言プログラムを受信するステップは、少なくとも２つの型の前記宣言プログラムの共通集合を表現する共通集合型である型の定義を受信するステップを含むことを特徴とする方法。
10. 請求項７に記載の方法であって、前記宣言プログラムを受信するステップは、少なくとも２つの型の前記宣言プログラムの和集合を表現する和集合型である型の定義を受信するステップを含むことを特徴とする方法。

Images