JP4794437B2 - 編集処理中にプログラムコンポーネントの整合性を表現しチェックするための拡張型システム - Google Patents

Description

本発明は、型システムに関し、詳細には、新しい及び更新されたプログラミング言語に拡張可能な型システムに関する。

型システムは、実行時エラーの発見及び防止を支援するためのプログラミング言語に用いられるシステムである。プログラミング言語は、変数、関数等のオブジェクトを宣言する型のセットを含む場合に「型付けされ（ｔｙｐｅｄ）」、これらの型は、言語で書かれたプログラムの編集中に、ルールセットと対比してチェックされる。型付き言語で書かれたソースコードが型ルールのうちのひとつに違反している場合に、コンピュータエラーが確定する。

コンパイラで使用するために、型付き中間言語はここ何年かで研究団体における重要な研究を受けた。これによって、コンパイラの信頼性及び堅牢性が高められ、また、ガーベッジコレクションに必要な情報を追跡し及びチェックするための体系的な方法が提供される。その案は、付属する型を有し、かつ、ソースプログラムの型チェックと類似の方法で型チェック可能である中間表現を有するべきである。しかしながら、編集処理中に明確にされたアイテムを表現する型が必要であるため、型付き中間言語を実装する（ｉｍｐｌｅｍｅｎｔ）のはより難しい。

型付き中間言語が多くの異なる高水準プログラミング言語をさらに表現しなければならない場合には、型付き中間言語は実装するのがさらに難しくなる。異なる言語は、異なる原始動作及び型を有しているばかりでなく、高水準プログラミング言語は、異なる水準の型付けを有している。例えば、アセンブリ言語等のいくつかの言語は、一般に型付けされない。言い換えれば、それらは型システムを有していない。型付けされた言語のうち、いくつかのものは強く（ｓｔｒｏｎｇｌｙ）型付けされ、他のものはより緩く（ｌｏｏｓｅｌｙ）型付けされる。例えば、Ｃ＋＋は一般的に緩く型付けされた言語と考えられている一方、ＭＬ又はＰａｓｃａｌは強く型付けされた言語と考えられている。さらに、緩く型付けされたいくつかの言語は、より小さい言語のサブセットを有している。そのサブセットにより、プログラムの中の主要コードセクションが強く型付けされ、他のコードセクションが緩く型付けされることが可能となる。例えば、Ｃ＃、及び、．ＮＥＴ（ＭＳＩＬ）において使用されるマイクロソフト（登録商標）中間言語により、これが可能となる。このため、任意のこれらの高水準言語を表すために使用される型付き中間言語は、異なる型強度を表すことができなければならない。同様に、型付き中間言語の型システムは、型がチェックされるコード文字に依存する、異なるルールを実現することができなければならない。

型付き中間言語が編集過程で低水準に移行した（ｌｏｗｅｒ）場合、別の問題が生じる。言語の低水準化は、プログラマが書くであろうもの等のより高い水準の形式から、中間言語等のより低い水準に、言語形式を変更する処理を参照する。さらに、言語は、中間言語から、マシーンに依存するネイティブコード等のコンピュータが実行するのに近い水準まで、より低水準化することが可能である。編集処理中に異なる水準に低められた中間言語の型をチェックするために、それぞれの表現のために異なるルールセットが使用されなければならない。

型付き中間言語を生成しようと試みることは、上述した問題を解決するのにはしばしば不十分である。例えば、Ｃｅｄｉｌｌａ ＳｙｓｔｅｍのスペシャルＪコンパイラは、型付き中間言語を使用する。しかしながら、このコンパイラは、Ｊａｖａ（登録商標）ソース言語に固有のものであり、このため、例えば、型なしセイフコード（ｎｏｎ−ｔｙｐｅ−ｓａｆｅ−ｃｏｄｅ）を有している複数の言語を処理する必要がない。さらに、このコンピュータは型チェックのために１つのルールセットのみを使用するため、コンピュータを複数の編集水準のために使用することができない。研究団体においては、型付き中間言語はしばしばソース言語に極めて固有である傾向があり、型付き中間言語を多数の編集段階のために設計する（ｅｎｇｉｎｅｅｒ）（及び、型を設計（ｄｅｓｉｇｎ）する）ことが困難である。

型の表現、型チェッカ、方法及びコンパイラは、中間言語の様々な形式における整合性をチェックするために提供される。特に、型付き中間言語は、型付き及び型付きでない言語と、緩くかつ強く型が付いた言語と、ガーベッジコレクションを行う及び行わない言語とを含む、複数の（異種の）ソース言語で書かれたプログラム表現における使用に適切である。さらに、異なる型及び原始的な動作を有する新しい言語を扱うために、型チェックアーキテクチャを拡張することができる。型、型チェック、方法及びコンパイラは、様々な態様を含んでいる。様々な態様は、別々かつ独立に使用することができ、又は、様々な態様は、様々な組み合わせ及び副次的な組み合わせで使用することができる。

ひとつの態様として、コンパイラにおけるプログラミング言語の型チェックの方法が提供される。１又は複数のルールセットが型チェッカへの入力として選ばれ（ｔａｋｅ ａｓ ｉｎｐｕｔ ｔｏ）、その型チェッカは、多数の基準のうちの、どれかひとつ、又は、複数の組み合わせに基づいて、１又は複数のルールセットを選択する。それらの中には、編集（ｃｏｍｐｉｌａｔｉｏｎ）段階、ソース言語、アーキテクチャ、及び、型チェックされた言語における現在の型水準が含まれる。選択された１又は複数のルールセットを用いて、その言語の型チェックが行われる。

他の態様として、コンパイラは、多数の基準のうちの、いずれか１つ、又は、１又は複数の組み合わせに基づいた、１又は複数のルールセットを構築する型チェッカとして提供される。ルールセットは、強い（ｓｔｒｏｎｇ）型チェックと対応する１つのルールセット、弱い（ｗｅａｋ）型チェックと対応する１つのルールセット、及び、表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）と対応する１つのルールセットを含むことが可能である。弱いルールセットは、型キャストを許容する等、型におけるさらなる柔軟性を許容するが、表現ルールセットは、中間プログラム表現の一部において落とされた型情報を許容する。

他の態様において、プログラムインターフェースは、プログラムの中間表現の整合性をチェックする複数のルールを構築するために提供される。中間表現の整合性をチェックすることは、予め定められた基準に基づいて、第１のルールセットを１つの中間表現に適用し、第２のルールセットを他の中間表現に適用する型チェッカに対して、複数のルールを提供することを含むことが可能である。

これらの及び他の態様は、添付図面を参照した後述する詳細な説明によって明らかになるであろう。

中間言語の様々な形式の整合性をチェックするために、型表現、型チェッカ、コンパイラが提供される。型チェッカ及びコンパイラは、プログラムコンポーネント（要素）及び／又は編集段階のためのソース言語に依存して、異なる型及び型チェックルールの使用を許容する。例えば、様々な言語で書かれたプログラムに適用される高水準のオプティマイザ（最適化ツール）を有することが望ましい。これらの言語は、異なる原始的な型、及び、原始的な動作を有する可能性がある。例えば、１つの言語は、複雑な計算を含むことができる一方、他の言語は、コンピュータグラフィックに特有の型及び操作を含むことができる。中間表現を異なる型のシステムによってパラメータ化できるようにすることで、異なる原始型及び操作を有する言語のためにオプティマイザを用いることが可能である。他の例はあるプログラムを含むことが可能であり、そのプログラムは、あるコンポーネントが強い型付き言語のサブセットで書かれており、かつ、他のコンポーネントが完全な言語（ｆｕｌｌ ｌａｎｇｕａｇｅ）で書かれているが、これはタイプセーフ（ｔｙｐｅ−ｓａｆｅ）ではない。第１のコンポーネントセットをチェックする、より多くのエラーを有することが望ましい。これは、異なるコンポーネントに対して異なる型チェックルールを使用することによって達成される。さらに、他の例として、編集中に落ちる型情報がある。初期の段階で正確な情報を保つように強制している間、型チェッカ及びコンパイラは、型情報を後の段階へと落とすようにすることが可能である。これは、異なる編集段階に対する異なる型チェックルールとの結合において、未知数型を使用することで達成可能である。

図１は、多くの異なるソース言語を表すための異なる低下した水準を有する、型付き中間表現を利用するシステムに対する一般的な編集処理である。ソースコード１００から１０６は、４つの異なるソース言語で書かれており、これらの４つの異なるソース言語は、型付けされ又は型付けされない可能性があり、異なる型強度水準を有する。例えば、Ｃ＃で書かれたソースコード１００は、Ｃ＋＋で書かれたソースコード１０６よりもより強く型付けされるであろう。ソースコードは、まずリーダ１０８によって処理され、システムに入力される。次に、ソース言語は、型付き中間表現のＨＩＲ（ｈｉｇｈ−ｌｅｖｅｌ ｉｎｔｅｒｍｅｄｉａｔｅ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ；高水準中間表現）に変換される。次に、ブロック１１０では、状況に応じてＨＩＲを分析及び最適化することが可能である。次に、ＨＩＲは、型付き中間表現のＭＩＲ（ｍｉｄ−ｌｅｖｅｌ ｉｎｔｅｒｍｅｄｉａｔｅ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ；中間水準中間表現）に変換される。この表現はＨＩＲよりも低いが、マシーンはいまだ独立している。この時点で、ブロック１１２に示すように、状況に応じてＭＩＲを分析及び最適化することが可能である。次に、ブロック１１４でのコード生成によって、ＭＩＲは、型付き中間表現のマシーンに依存するＬＩＲ（ｌｏｗ−ｌｅｖｅｌ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ；低水準表現）に変換される。次に、ブロック１１６において、ＬＩＲは状況に応じて分析及び最適化され、ブロック１１８においてエミッタに供給される。エミッタは、システムに読み込まれたオリジナルソースコードを表す多くの形式１２０−１２６のうちのひとつにおけるコードを出力するであろう。このプロセスを通じて、プロセスを完成するのに必要なデータは、永続性（ｐｅｒｓｉｓｔｅｎｔ）メモリ１２８に保存される。

従って、編集プロセスは、１つの水準の表現から他の水準の表現への中間言語命令の変換で構成される。例えば、図２は、マシーンに依存したＬＩＲへのＨＬＲの変換と共に、ＨＩＲへのソースコードステートメントの変換を示している。多数の高水準のプログラミング言語でソースコードステートメント２００を書くことが可能である。これらの言語は、容易に理解される方法でプログラマが読み書き可能なように設計されている。従って、プログラマは、「＋」等の文字を加算に使用することができ、ステートメント２００で示されるように、２つ以上のオペランドを加算する等、プログラマはより強力な形式を使用可能となる。

ステートメント２０２〜２０６は、同じ機能を表現するステートメント２００のＨＩＲ表現である。しかしながら、ステートメント２０２〜２０６は、コンピュータが理解できるが、依然としてアーキテクチャには依存しないフォーマットに近い。ステートメント２０２は、「ＡＤＤ」コマンドを使用して、第１又は第２の変数を加算し、結果を第１の一時的な変数ｔ１に代入する。次に、ステートメント２０４は、別の「ＡＤＤ」コマンドを使用して、ｔ１を第３の変数に加算し、結果を第２の一時的な変数ｔ２に代入する。次に、ステートメント２０６は、「ＡＳＳＩＧＮ」命令を使用して、ｔ２の値を結果変数ｚに代入する。

ステートメント２０８〜２１２は、ステートメント２０２〜２０６の中間言語のＬＩＲである。ステートメント２０８は、ｘ８６アーキテクチャに特有の加算命令を使用して、特定のレジスタに保存されている２つの変数の値を加算し、一時的な変数ｔ１に割り当てられているレジスタの中に結果を保存する。ステートメント２１０は、ｘ８６アーキテクチャに特有の加算命令を使用して、変数ｔ１と特定のレジスタに保存されている第３の変数と加算し、ｔ２に割り当てられている特定のレジスタ（ＥＡＸ）に結果を保存する。次に、ステートメント２１２は、ｘ８６アーキテクチャに特有の移動命令を使用して、ＥＡＸに保存されている値を出力変数ｚに移動する。

型チェックを実行するために、型付き中間言語は、明確又は不明確に表現された型表現を含む。明確な型表現は、表現において直接的に宣言される。例えば、ステートメント
ｉｎｔ ａ；
は、明確に変数「ａ」を整数型として定義する。あるコードのステートメントについてのデフォルト型として定義することで、型表現を不明確に表現することも可能である。例えば、関数に対するデフォルトの戻り型が整数の場合、ステートメント
ｆ＿ｓｔａｒｔ（）；
は、引数を何も持たず、かつ、整数型の値を返す、関数ｆ＿ｓｔａｒｔを宣言する。

複数の表現水準での複数のプログラミング言語の使用に適した型付き中間言語についての型表現の一実施形態は、別表（Ａｐｐｅｎｄｉｘ）Ａに示されている。これは、多数のあり得る実施形態のほんの一例であることに留意されたい。

別表Ａに言及すると、多くの型表現が型クラス階層で定義されるため、様々な言語の型システムを型付き中間言語で表現することが可能である。抽象的な基本クラスは、全ての型について「Ｐｈｘ：：Ｔｙｐｅ」と定義される。例えば、基本クラスは、実際（ａｃｔｕａｌ）型、象徴（ｓｙｍｂｏｌｉｃ）型又は未知数（ｕｎｋｏｗｎ）（又は変数）型等の、様々な型に対する「ｓｉｚｅｋｉｎｄ」の中にサイズ情報を含むことが可能である。基本クラスは、型の分類を指定するために、「ｔｙｐｅｋｉｎｄ」も含むことも可能である。さらに、型付き中間言語からオリジナルのソースコードへのマッピングを提供するために、外部で定義された型をラップする（ｗｒａｐ）抽象型として外部型を提供することが可能である。

基本クラスの下では、「Ｐｈｘ：：ＰｔｒＴｙｐ」として定義されたクラスは、ポインタ型を表現することが可能である。同様に、様々なポインタを定義可能である。例えば、管理されたガーベッジコレクトポインタ（ｇａｒｂａｇｅ ｃｏｌｌｅｃｔｅｄ ｐｏｉｎｔｅｒ）（ガーベッジコレクトオブジェクトの範囲内の位置を指す）、管理されたノンガーベッジコレクトポインタ（ノンガーベッジコレクトオブジェクトの範囲内の位置を指す）、管理されていないポインタ（例えば、Ｃ＋＋で書かれたコードの中で見つけられる等）、参照ポインタ（ガーベッジコレクトオブジェクトのベースを指す）、及び、ナルがある。

階層における同じ水準において、「Ｐｈｘ：：ＣｏｎｔａｉｎｅｒＴｙｐｅ」として定義されるクラスは、内部のメンバーを含む型など、コンテイナ型を表すことが可能である。内部のメンバーは、フィールド、方法及び他の型を有することが可能である。「Ｐｈｘ：：ＦｕｎｃＴｙｐｅ」として定義されるクラスは、任意の必要な呼び出し仕様（ｃｏｎｖｅｎｔｉｏｎ）、引数のリスト及び戻り型のリストを含んだ、関数型を表すことが可能である。また、「Ｐｈｘ：：ＵｎｍｇｄＡｒｒａｙＴｙｐｅ」として定義されたクラスは、管理されない配列型を表すことも可能である。階層における「Ｐｈｘ：：ＣｏｎｔａｉｎｅｒＴｙｐｅ」の下では、さらに４つのクラスを定義可能である。「Ｐｈｘ：：ＣｌａｓｓＴｙｐｅ」として定義されるクラスはクラス型を表すことが可能であり、「Ｐｈｘ：：ＳｔｒｕｃｔＴｙｐｅ」として定義されるクラスは構造型を表すことが可能であり、「Ｐｈｘ：：ＩｎｔｅｒｆａｃｅＴｙｐｅ」として定義されるクラスはインターフェース型を表すことが可能であり、「Ｐｈｘ：：ＥｎｕｍＴｙｐｅ」として定義されるクラスは列挙型を表すことが可能である。階層における「Ｐｈｘ：：ＣｌａｓｓＴｙｐｅ」の下では、「Ｐｈｘ：：ＭｇｄＡｒｒａｙＴｙｐｅ」として定義される追加クラスは、管理される配列型を表すことが可能である。

別表Ａの中で示される表現において、クラス「ｐｒｉｍｔｙｐｅ」は、構造型の特別なインスタンスとして定義される。「ｐｒｉｍｔｙｐｅ」は、整数、浮動小数、未知数、虚数、条件コード、符号なし整数、ｘ整数（ｘｉｎｔ）等、様々な型を含むことが可能である。これらの表現は、型付き中間言語のＨＩＲ又はＬＩＲの両方で使用可能である。

さらに、目標とする特別な原始型を型表現に含むことが可能である。もし、型システムが汲み取る（ｍａｄｅ ａｗａｒｅ ｏｆ）ならば、いくつかの言語は、効果的に扱われることが可能な複雑な計算型を有する。「ＭＭＸ」命令を例にとる。このような命令は、マルチメディアデータ型及び通信データ型に対する単一の命令／複数のデータ操作をサポートするために、ｘ８６プロセッサのあるバージョンの中に構築される特別な命令セットのひとつである。型システムをカスタマイズして、型表現の最小限の交代でこれらの命令を認識し使用することが可能である。

別表Ａの中で示される型の型表現の実施形態には、「未知数」型も含まれる。この「未知数」型は、任意の型を表現することが可能であり、状況に応じて、それに関連するサイズを有する。サイズは、値のマシーン表現のサイズである。未知数型によって、コンパイラは、特定の型から未知数型へ型情報を変化させることによって、制御された方法で型情報を落とすことが可能となる。型が未知数であったとしても、未知数によって、コンパイラは、操作される値のサイズに依存するコードを生成することが可能となる。他の型は未知数型を使用することができ、このため、未知数型も、（いくつか、しかし、全てではない情報が知られている場合に）部分的に型情報の表現を許容する。

例えば、整数型へのポインタを想定する。低水準化したある段階では、型情報としての整数を落とすことが望ましい場合がある。未知数型によって、コンパイラは整数型を未知数型に置き換えることが可能となる。型チェッカは、関係（ｉｎｔｅｒｅｓｔ）のポインタが正しい型を指していることをチェックする必要がない。それは、実行時において、指し示されている値が、プログラム機能に不利に影響しないように扱われる機会を本質的に得る。

他の例として、関数型を定義するために未知数型を使用する。引数が前もって整数への型ポインタを有している場合、未知数への型ポインタの引数とともに関数が呼び出されると、コンパイラは正しい型が渡された（ｐａｓｓ）と信用しなければならない。ポインタの参照解除の結果として、整数であることが知られても知られなくてもよいが、しかしながら、その結果は整数として使用されるであろう。より複雑な例は、仮想関数呼び出しの高水準中間表現から低水準中間表現への変換中における、中間の一時的な変数の導入である。仮想テーブル（ｖテーブル）は、オブジェクト指向言語における仮想呼び出しを実現するために広く使用されている。低水準中間表現における仮想関数呼び出しを作成する最初のステップは、オブジェクトメモリの第１のフィールドにフェッチ（ｆｅｔｃｈ）することである。第１のフィールドはｖテーブルへのポインタを含んでいる。フェッチの結果は、一時的な変数に割り当てられる。一時的な変数型（ｖテーブルが多くのフィールドを保持することができる場合、ｖテーブルへのポインタを表現する型）を構築することは、表現するのに複雑で煩わしい場合がある。代わりに、コンパイラは、中間の一時的な変数「未知数への変数」を単に割り当てることができる。詳細な型情報を保つことが必要ない場合、又は、詳細な型情報を保つことがコンパイラの開発者にとって大きな負担となるかもしれない場合、このように、未知数型を使用することで編集の後の段階が単純になる。

図３は、編集の様々な段階で型付き中間言語の型チェックを行うための、ひいては、様々な低水準型付き中間言語の型チェックを行うための、コンパイラシステムの一実施形態を示している。ソースコード３００は、ソース言語の多様性のうちのいずれかひとつを表現している。ソースコード３００は型付き中間言語３０２のＨＬＲに変換される。その時に、ソース言語の型表現は型付き言語内部の型表現に変換される。

図１及び２に関して説明したように、ＨＩＲは編集処理を通じて低水準化される。この説明図の目的として、高い（ＨＩＲ）３０２、中間（ＭＩＲ）３０４、及び低い（ＬＩＲ）３０６水準表現が示されている。しかしながら、実施形態はこれに限定されない。任意の数の編集段階を型チェックすることができる。

型チェッカ３０８は、それぞれの水準表現での中間言語を型チェックすることができる。型チェッカ３０８は、編集処理のそれぞれの段階に、ひいては、中間言語のそれぞれの表現に、１又は複数のルールセット３１０を適用するためのアルゴリズム又は手順を実行する。ルールセット３１０は、ソース言語、編集段階、型付きの強度等、言語の特質（ｐｒｏｐｅｒｔｙ）を変えるために設計されたルールセットである。

例えば、ソースコード３００がＣ＋＋プログラミング言語で書かれたコードを含むと想定する。Ｃ＋＋ソースコード３００は、まず型付き言語のＨＩＲ３０２に変換される。必要なら、この時点で、型チェッカ３０８は特質の任意の数を決定するために、ＨＩＲ３０２と情報をやりとりすることが可能である。このような特質は、編集の段階（ＨＩＲ）、現在のソースコード型（Ｃ＋＋）、言語が型付けされているか否か（ｙｅｓ）、言語が緩く又は強く型付けされているか（ｌｏｏｓｌｙ）等を含むことができる。特質に基づいて、型チェッカは適切なルールセットを選択することが可能である。ルールが選択されると、型チェッカは、ルールセットに従ってＨＩＲの型チェックを行う。ＨＩＲがＭＩＲ又はＬＩＲに低水準化されると、特質は再びアクセスされ、同じ又は異なるルールセットが適合することができる。

一実施形態では、型チェッカは３セットの型チェックルールの提供を受けることが可能である。１つのセットは、Ｃ＃又はＭＳＩＬの型チェックに望ましい「強い」型チェックに対応することが可能である。他のセットは、「強い」型チェックよりも緩い型チェックを行う「弱い」型チェックに対応することが可能である。例えば、弱い型チェックルールセットは、型キャストを許可することが可能である。型キャストは、ひとつの型の変数が単一の用途のために他の型と同じ動作をさせられる場合をいう。例えば、整数型変数をｃｈａｒ（文字）と同じに動作させることが可能である。次のコードは、型キャストを用いて、文字「Ｐ」を印刷する。
ｉｎｔ ａ；
ａ＝８０；
ｃｏｕｔ＜＜（ｃｈａｒ）ａ；
従って、「ａ」が整数型として定義され、値８０に割り当てられていたとしても、ｃｏｕｔステートメントは、型キャストのために変数「ａ」を文字型として扱い、従って、８０ではなく「Ｐ」（アスキー値８０）を表示する。

最後に、セットは「表現」チェックと対応することが可能である。「表現」チェックは、未知数を使用等することにより、中間プログラム表現の一部において落ちた型情報を許容することが可能であり、そのような型の情報を落とすことが可能な場合、又は、未知数型を別の型で置換可能な場合に、命令するルールを含むことが可能である。例えば、虚数型の値を返す関数の結果を、虚数型の変数に割り当てることを禁止することができる。

さらに、１セット以上のルールを編集の単一段階で使用することが可能である。例えば、ソースコード３００は単一の言語を含んでいるが、強く型付けがされている複数のセクション及び緩く型付けがされているいくつかのセクションを含んでいると想定する。タイプチェッカは、ある強く型付けされたセクションでのＨＬＲに対する１つのルールセット、及び、緩く型付けされたコードセクションに対する他のルールセットを使用することが可能である。

図４は、図３における説明と同じコンパイラシステム用の型チェッカのブロック図である。型チェッカ４００は、異なるソース言語及び／又は異なる編集段階と対応するルールセットの任意の数を、入力として受け取ることが可能である。図４において、４つのルールセット４０２〜４０８が型チェッカ４００に提供される。ルールセット４０２は、強く型付けされた言語のＨＩＲに対するルールセットを表し、ルールセット４０４は、弱く型付けされた言語のＨＩＲに対するルールセットを表し、ルールセット４０６は型が付けられていない言語のＨＩＲに対するルールセットを表し、ルールセット４０８はＬＩＲに対するルールセットを表す。プログラムモジュール４１０は、ＨＬＲにおいて強く型付された言語を表し、プログラムモジュール４１２は、ＬＩＲに低水準化された後のプログラムモジュール４１０を表す。

型チェッカ４００は、型チェックがなされたプログラムモジュールの特質に基づいて適切なルールセットを選択し、連携した手順又はアルゴリズムを使用して、選択されたルールをプログラムモジュールに適用する。例えば、型チェッカ４００は、（ＨＩＲにおいて強く型付けされた言語を表す）プログラムモジュール４１０の型をチェックするために、（強く型付けされた言語のＨＩＲのルールセットを表す）ルールセット４０２を選択することができる。続いて、型チェッカ４００は、（ＬＩＲにおいて強く型付けされた言語を表す）プログラムモジュール４１２の型をチェックするために、（ＬＩＲに対するルールセットを表す）ルールセット４０８を選択する。

図５は、型チェッカによって適用されるルールセットを選択するための手順の、一つのあり得る実施形態のフローチャートである。ブロック５００では、型チェッカはソースコードの型付き中間表現のセクションを読み込み、型チェックのためのルールを選択しなければならない。決定５０２は、型付き中間言語がＨＩＲ、ＭＩＲ、又は、ＬＩＲかを決定する。

ＨＩＲ又はＭＩＲである場合、決定５０４は、オリジナルソースコードが緩く又は強く型付けされているかを決定する処理を行う。緩く型付けされている場合、ブロック５０６は、弱い型チェックと対応するルールセットを選択する処理を行う。強く型付けがされている場合、ブロック５０８は、強い型チェックと対応するルールセットを選択する処理を行う。

型付き中間言語がＬＩＲの場合、決定ブロック５１０は、表現型チェックと対応するルールセットを選択する処理を行う。図５は単なる一実施形態であることに留意すべきである。異なる特質に対応して、及び、異なる特質に基づいて、ルールセットの任意の数を選択可能である。

説明した型チェックシステムのルールセットは、完全に新しい言語に、さらに、従来言語の新しい機能にも、容易に拡張される。例えば、新しい言語が導入されると、新しいルールセットは新しい言語のために容易に記述される。ルールセットは型チェッカ又はコンパイラシステム自体から分離され、ルールセットを分離されたエンティティとして受け入れるよう設計されるため、既存の型チェックシステム又はコンパイラを再分配又は更新することなく、新しい言語に対する新しいルールセットを分配することが可能となる。同様に、例えばＣ＋＋をサポートする追加ＸＭＬ等、新しい機能が既存の言語に追加された場合、編集の様々な段階でＣ＋＋に対応するルールセットを動的に容易に再構成し、新しい機能を扱うことが可能となる。この場合も、新しい中核のシステムを更新したり分配したりする必要はない。

ルールセットにより型編集を許容することも可能である。例えば、クラスが他から継承された場合に副次的な型付け（ｓｕｂ−ｔｙｐｉｎｇ）が特定の型に許容されるか否かを、ルールに記述される制約とすることができる。別の制約として、データをそのデータが含まれる仮想テーブルに変換可能であることの通知が所望される等の、箱詰めの（ｂｏｘｅｄ）制約があり得る。他には、サイズの制約、又は、同一の原始型の必要性を示す原始的な型制約を含むことができる。任意の他のルールセットの一部と同様に、新しい制約を所望のとおりに追加することが可能である。

ルールセットを記述するためのアプリケーションプログラミングインターフェースを介して、型チェッカによって使用されるルールセットを構築することが可能である。アプリケーションはルールを構築することが可能であり、ルールセットは、ルールが型付き中間言語の個々の命令に割り当てられている、原始型の階層で表される。特別なプログラムモジュール又は編集ユニットと関係のある様々な型の要素を明確に表現する型グラフの形式で、階層を供給することが可能である。シンボル及び操作等、ＩＲ要素は、型システムのエレメントと関連づけられるであろう。型グラフノードは、原始的な型及び構築された型と、これらの関係とを記述する。例えば、コンポーネント、ネスト型、関数署名（ｓｉｇｎａｔｕｒｅ）、インターフェース型、階層要素、及び、ソース名、モジュール／アセンブリの外部型要素への参照等の他の情報等がある。

シンプル型のルールの例は以下の通りである。
ＡＤＤ
Ｎ＝ａｄｄ ｎ，ｎ
この例の目的として、Ｉが符号付整数型、Ｕが符号なし整数型、Ｘがどちらかの整数型、Ｆが浮動小数点、Ｎが以上のいずれでもあると想定する。図６は、これらの型の間の階層的な関係を示している。型Ｎは階層の頂点である。型Ｆ及びＸは、階層の後続の水準を形成するために、型Ｎから下方に分岐している（ｂｒａｎｃｈ ｄｏｗｎ）。最後に、型Ｕ及びＩは、階層の最も低い水準を形成するために、Ｘ型から下方に分岐している。従って、「ＡＤＤ」という中間言語命令に対しては、このルールに従って、加算（ａｄｄ）命令が、Ｎ型又はより階層の低い型のみを実行することが可能であり、オペランドは階層において結果よりも高くなる必要はない。例えば、２つの整数を加算して整数を生成する（Ｉ＝ＡＤＤｉ，ｉ）ことが可能であるか、又は、整数及び浮動小数点を加算して浮動小数点を生成する（Ｆ＝ＡＤＤｉ，ｆ）ことが可能である。しかしながら、浮動小数点及び整数を加算して整数を生成する（Ｉ＝ＡＤＤｉ，ｆ）ことは不可能である。

階層として原始型を表現することにより、ルールセットを容易に変化させることが可能となる。過去において、型ルールは、ソースコードを使用してプログラムでしばしば表現されてきた。例えば、型チェッカは、型チェックルールを実行する多くのスイッチステートメントを含むことができる。従って、型チェッカのためにソースコードを修正するというルールの変更が要求された。しかしながら、階層ルールセットは、より容易に拡張性を提供する。上述したＡＤＤ命令のルールを考える。開発者が、例えば、型Ｃを混合型に加算したい場合、図７に示す階層の中で、Ｎ型の下でそれを容易に加算することが可能であり、ＡＤＤ命令のルールを所望の関数に変更する必要はない。

図８には、型チェックシステムにおいて型ルールに対する命令をチェックするための１つの方法が示されている。まず、ブロック８００において、構文的な命令のチェックの処理が行われる。従って、８０６における命令を考えると、型チェッカは、ＡＤＤ命令の型ルールに従って（例えば、この場合には、２つのソース表現と１つの送り先（ｄｅｓｔｉｎａｔｉｏｎ）の表現がある）、正確な数のソース及び送り先の表現が存在することを確実にする。それぞれの表現（及び副次的な表現）は、中間表現の中で明示（ｅｘｐｌｉｃｉｔ）型を有することができる。ブロック８０２においては、型チェッカは、ｅ１、ｅ２及びｆｏｏ（ｅ３）に対する明示型がＡＤＤ命令の型ルールに従っていることを、実際に検証する。ブロック８０４において、型チェッカは、必要ならば副次的な水準を超えて、型チェック命令を進める。例えば、型チェッカは、表現ｅ１、ｅ２、及びｆｏｏ（ｅ３）が明示型からなることをチェックすることが可能である。例えば、型チェッカは、ｆｏｏが関数型を有することをチェックすることができる。型チェッカは、関数型の結果型がｆｏｏ（ｅ３）の明示型と同じことをチェックすることができる。単一の引数型が存在し、ｅ３の型がその型に一致することを、型チェッカはさらにチェックすることができる。これによって、ｅ３への呼び出し型が型ルールと整合していることが保証される。

図９は、型チェックシステムの操作環境としての役目を果たすコンピュータシステムの例を示す。コンピュータシステムは、処理装置９２１と、システムメモリ９２２と、処理装置９２１へのシステムメモリを含む様々なシステムコンポーネントを相互接続するバス９２３とを含む、パーソナルコンピュータ９２０を含む。システムバスは、メモリバス又はメモリコントローラ、周辺バス、及び、少し例を挙げると、ＰＣＩ、ＶＥＳＡ、マイクロチャネル（ＭＣＡ）、ＩＳＡ及びＥＩＳＡ等のバスアーキテクチャを用いたローカルバスを含む、いくつかの種類のバス構成のうちのいずれかで構成することができる。システムメモリは、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９２４、及び、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９２５を含む。起動時等にパーソナルコンピュータ９２０内の要素間の情報送信を支援する基本ルーチンを備えるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）９２６は、ＲＯＭ９２４に格納されている。パーソナルコンピュータ９２０は、リムーバブルディスク９２９及び例えばＣＤ−ＲＯＭディスク９３１を読むための光ディスクドライブ９３０を読み書きするために、又は、他の光媒体を読み書きするために、ハードディスクドライブ９２７、磁気ディスクドライブ９２８等をさらに含む。ハードディスクドライブ９２７、磁気ディスクドライブ９２８、及び、光ディスクドライブ９３０は、それぞれ、ハードディスクドライブインターフェース９３２、磁気ディスクドライブインターフェース９３３、光ディスクドライブインターフェース９３４によって、システムバス９２３に接続されている。ドライブ及びそれらに関連するコンピュータ読取可能な媒体は、不揮発性のデータ記憶装置、データ構造、コンピュータ実行可能な命令（動的リンクライブラリ、実行可能なファイル等のプログラムコード）等をパーソナルコンピュータ９２０に提供する。上述したコンピュータ読取可能な媒体の説明では、ハードディスク、リムーバブル磁気ディスク及びＣＤに言及したが、磁気カセット、フラッシュメモリカード、デジタルビデオデスク、ベルヌイカートリッジ等、コンピュータが読み取り可能な他の種類の媒体を含むことも可能である。

オペレーションシステム９３５と、１又は複数のアプリケーションプログラム９３６と、他のプログラムモジュール９３７と、プログラムデータ９３８とを含む、ドライブ及びＲＡＭ９２５に、多くのプログラムモジュールを格納することができる。ユーザは、キーボード９４０、及び、マウス９４２等のポインティングデバイスを介して、コマンド及び情報をパーソナルコンピュータ９２０に入力することができる。他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナ等を含むことができる。これらの及び他の入力デバイスは、しばしば、パラレルポート、ゲームポート又はＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）等の、システムバスに連結されたシリアルポートインターフェース９４６を介して、処理装置９２１に接続される。モニタ９４７又は他の種類のディスプレイデバイスも、ディスプレイコントローラ又はビデオアダプタ９４８等のインターフェースを介して、システムバス９２３に接続される。モニタに加えて、パーソナルコンピュータは、通常、スピーカ、プリンタ等の他の周辺出力装置（図示せず）を含む。

パーソナルコンピュータ９２０は、リモートコンピュータ９４９等の、１又は複数のリモートコンピュータへの論理的接続を使用して、ネットワーク環境において動作することができる。リモートコンピュータ９４９は、サーバ、ルータ、同等のデバイス又は他の一般的なネットワークノードであることができ、通常、パーソナルコンピュータ９２０に関連して記述される多くの又は全ての要素を含むが、図９にはメモリストレージデバイス９５０のみが示されている。図９に示される論理的接続は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）９５１及びＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）９５２を含む。このようなネットワーク環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット及びインターネットにおいて一般的である。

ＬＡＮネットワーク環境において使用された場合、パーソナルコンピュータ９２０は、ネットワークインターフェース又はアダプタ９５３を介してローカルネットワーク９５１に接続される。ＷＡＮネットワーク環境で使用される場合、パーソナルコンピュータ９２０は、通常、インターネット等の、モデム９５４又はＷＡＮ９５２を介して通信を確立するための他の手段を含む。モデム９５４は、内部にあっても外部にあってもよいが、シリアルポートインターフェース９４６を介してシステムバス９２３に接続されている。ネットワーク環境において、パーソナルコンピュータ９２０又はその部分に関連づけて表されるプログラムモジュールを、遠隔記憶装置に格納することができる。示したネットワーク接続は例示に過ぎず、コンピュータ間の通信リンクを確立する他の手段を使用することができる。

実施形態の原理を図示し記述したが、当業者がその原理から離脱することなく構成及び詳細を変更することが可能なことは明らかであろう。

例えば、ここでの一実施形態では、型チェッカ又はコンパイラに供給可能な１又は複数のルールセットについて説明した。コンパイラ又は型チェッカが１又は複数のルールセットを選択し、言語及び／又は型チェックされている編集段階に基づいて言語の型チェックを行うと説明した。しかしながら、代わりに、型チェッカ又はコンパイラに１つのルールセットを供給し、言語及び／又は型チェックされている編集段階に基づいて、実行中に静的又は動的のいずれかで、型チェッカ又はコンパイラが１又は複数のルールのサブセットを構築することが可能である。

多くの可能性のある実施形態の観点では、示した実施形態は例示に過ぎず、本発明の範囲において限定ととらえるべきでないことがわかるであろう。むしろ、本発明は特許請求の範囲で定義される。従って、特許請求の範囲内に含まれるすべての実施形態を本発明として主張する。

一般的な編集処理のフロー図である。 高水準表現、及び、次に、マシーンに依存する低水準表現への、ソースコードステートメントの変換を示すテーブルリストである。 編集の様々な段階において型付き中間言語の型チェックのためのコンパイラシステムの一実施形態を示すデータフロー図である。 コンパイラシステム用の型チェッカのブロック図である。 型チェッカによって適用されるべきルールセットを選択するための１つの可能な手順のフローチャートである。 型間の階層的な関係を示す有向グラフダイアグラムである。 型間の階層的な関係に対する追加の型を示す有向グラフダイアグラムである。 型チェックシステムにおいて、型ルールに対する命令をチェックするための方法のフローチャートである。 型チェックシステムの実施形態のためのオペレーティング環境としての役割を果たすコンピュータシステムの例のブロック図である。

Claims (10)

1. コンパイラシステムにおいて、複数のソース言語で各々記述されるプログラムモジュールの型を、ルールセットに従ってチェックするための方法であって、
   特定のソース言語で記述されたプログラムモジュールをソースコードから中間表現に変換する編集段階が、高水準の中間表現を表す第１の段階と、中間水準の中間表現を表す第２の段階と、低水準の中間表現を表す第３の段階のうちのいずれの段階であるかを決定することと、
   前記プログラムモジュールの前記特定のソース言語および前記決定された編集段階に基づいて、前記コンパイラシステムにおいて構築された複数のルールセットから、前記プログラムモジュールの型チェックに使用すべきルールセットを選択することと、
   前記選択されたルールセットに従って前記プログラムモジュールの型チェックを行うことと
   を含み、
   前記複数のルールセットは、少なくとも、強い型チェックに対応するルールセットと、弱い型チェックに対応するルールセットと、表現の型チェックに対応するルールセットとを含み、
   前記プログラムモジュールの前記特定のソース言語および前記決定された編集段階に基づいて、前記プログラムモジュールの型チェックに使用すべきルールセットを選択することは、
   前記編集段階が前記第１または第２の段階であるとき、前記特定のソース言語が強く型付けされている場合、前記複数のルールセットから前記強い型チェックに対応するルールセットを選択し、前記特定のソース言語が緩く型付けされているとき、前記複数のルールセットから前記弱い型チェックに対応するルールセットを選択することと、
   前記編集段階が前記第３の段階であるとき、前記複数のルールセットから前記表現の型チェックに対応するルールセットを選択することと
   を含むことを特徴とする方法。
2. 前記プログラムモジュールの型チェックを行うことは、前記プログラムモジュールの前記第１の中間表現、前記第２の中間表現、および前記第３の中間表現それぞれの型チェックを行うことを含むことを特徴とする請求項１に記載の方法。
3. 前記プログラムモジュールは、該プログラムモジュールの要素を複数の型のうちのいずれかの型とすることを示す型を含むことを特徴とする請求項１に記載の方法。
4. 前記選択されたルールセットは、前記プログラムモジュールの要素を複数の型のうちのいずれかの型とすることを示す前記型を型チェックするためのルールを含むことを特徴とする請求項３に記載の方法。
5. 前記複数のルールセットはそれぞれ、階層形式の複数のルールを備えることを特徴とする請求項１に記載の方法。
6. 前記表現の型チェックは、前記プログラムモジュールの前記ソースコードの要素に対する型情報が前記第３の中間表現では落ちることを許容することを特徴とする請求項１に記載の方法。
7. 前記弱い型チェックは、型キャストを許容することを特徴とする請求項１に記載の方法。
8. ソース言語で記述されたプログラムモジュールをコンパイルするためのコンパイラシステムであって、
   少なくとも、強い型チェックに対応するルールセットと、弱い型チェックに対応するルールセットと、表現の型チェックに対応するルールセットとを含む、プログラムモジュールを型チェックするための複数のルールセットと、
   前記プログラムモジュールの編集段階を決定し、該決定した編集段階と前記プログラムモジュールが記述された前記ソース言語とに少なくとも部分的に基づいて、前記複数のルールセットから、前記プログラムモジュールの型チェックに使用すべき１つまたは複数のルールを選択する型チェッカと
   を備え、
   前記編集段階は、高水準の中間表現を表す第１の段階と、中間水準の中間表現を表す第２の段階と、低水準の中間表現を表す第３の段階とのうちのいずれかであり、
   前記型チェッカは、
   前記プログラムモジュールの前記編集段階が、前記第１の段階と、前記第２の段階と、前記第３の段階のいずれであるかを決定し、
   前記編集段階が前記第１の段階または前記第２の段階であるとき、前記プログラムモジュールの前記ソース言語が強く型付けされている場合は前記複数のルールセットのうち前記強い型チェックに対応するルールセットを選択し、前記プログラムモジュールの前記ソース言語が緩く型付けされている場合は前記複数のルールセットのうち前記弱い型チェックに対応するルールセットを選択し、
   前記編集段階が前記第３の段階であるとき、前記複数のルールセットのうち前記表現の型チェックに対応するルールセットを選択すること
   により、前記１つまたは複数のルールを選択することを特徴とするコンパイラシステム。
9. 前記表現の型チェックは、前記プログラムモジュールのソースコードの要素に対する型情報が前記第３の中間表現では落ちることを許容することを特徴とする請求項８に記載のコンパイラシステム。
10. 前記弱い型チェックは、型キャストを許容することを特徴とする請求項８に記載のコンパイラシステム。

Images