(57)【要約】  型、型チェッカ及びコンパイラは様々な中間言語の形式の整合性をチェックするために提供される。１又は複数のルールセットを多数の基準とみなすことでコンパイラでのプログラミング言語の型チェックが達成される。それらの中には、編集段階、ソース言語、アーキテクチャ及び型チェックされた言語における現在の型水準が存在する。言語は選択された１又は複数のルールセットを使用して型チェックされる。ルールセットは、強いタイプチェック、弱いタイプチェック及び表現型チェックと対応するそれぞれ１つのルールセットを含むことが可能である。代替として、実行時に上記基準の何れか１つ又は複数の組み合わせに基づきより多いルールセットから１又は複数のルールセットを構築する型チェッカに、コンパイラを提供することが可能である。【特許請求の範囲】
【請求項１】
１又は複数のルールセットに従った、コンパイラにおけるプログラミング言語の型チェックの方法であって、
現在の編集段階に基づいて１又は複数のルールセットを選択することと、
前記選択された１又は複数のルールセットに基づいて前記プログラミング言語の型チェックを行うことと
を備えることを特徴とする方法。
【請求項２】
前記１又は複数のルールセットを選択することは、前記編集段階よりも前記プログラミング言語の特性（ｃｈａｒａｃｔｅｒｉｓｔｉｃ）に基づいていることを特徴とする請求項１に記載の方法。
【請求項３】
前記プログラミング言語の前記特質は、前記言語の前記型システムを記述することを特徴とする請求項２に記載の方法。
【請求項４】
前記プログラミング言語の型チェックを行うことは、前記プログラミング言語の複数の中間表現のそれぞれを型チェックすることを備えることを特徴とする請求項１に記載の方法。
【請求項５】
前記選択された１又は複数のルールセットは、それぞれの表現で異なることを特徴とする請求項４に記載の方法。
【請求項６】
前記１又は複数のルールセットを選択することは、前記編集段階よりも型チェックされた前記表現の特質に基づくことを特徴とする請求項４に記載の方法。
【請求項７】
前記プログラミング言語は、該プログラミング言語の要素を複数の型のうちのひとつとすることが可能であることを示す型を含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記１又は複数のルールセットは、前記プログラミング言語の要素を複数の型のうちのひとつとすることが可能であることを示す型を、型チェックするためのルールを含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記１又は複数のルールセットは、階層形式における複数のルールを備えることを特徴とする請求項１に記載の方法。
【請求項１０】
前記１又は複数のルールセットは、強い型チェックに対応するひとつのルールセット、弱い型チェックに対応する１つのルールセット、及び、表現の型チェックに対応するルールセットを備えることを特徴とする請求項１に記載の方法。
【請求項１１】
前記表現の型チェックは、前記プログラミング言語の要素に対する型情報が落ちることを許容することを特徴とする請求項１０に記載の方法。
【請求項１２】
前記弱い型チェックは、型キャストを許容することを特徴とする請求項１０に記載の方法。
【請求項１３】
ソース言語で書かれたソースコードをコンパイルするためのコンパイラであって、
複数の型ルールと、
前記ソース言語に基づいて前記複数の型ルールから型ルールのサブセットを選択し、ルールセットを構築する型チェッカと
を備えることを特徴とするコンパイラ。
【請求項１４】
前記型ルールの前記サブセットは、前記ソース言語よりも前記ソースコードの中間表現に基づいて選択されることを特徴とする請求項１３に記載のコンパイラ。
【請求項１５】
前記型ルールの前記サブセットは、前記ソース言語よりも編集段階に基づいて選択されることを特徴とする請求項１３に記載のコンパイラ。
【請求項１６】
３つのルールセットが構築されており、ひとつは強い型チェックに対応し、ひとつは弱い型チェックに対応し、ひとつは表現型チェックに対応することを特徴とする請求項１３に記載のコンパイラ。
【請求項１７】
前記表現型チェックは、ソースコードの要素に対する型情報が落ちることを許容することを特徴とする請求項１６に記載のコンパイラ。
【請求項１８】
前記弱い型チェックは、型キャストを許容することを特徴とする請求項１６に記載のコンパイラ。
【請求項１９】
複数のソース言語で記述されたソースコードの型チェックを行うための型チェックシステムであって、
複数のルールセットと、
１又は複数のルールセットを選択して、複数の表現それぞれに前記ソースコードを適用する型チェッカと
を備えることを特徴とするシステム。
【請求項２０】
前記選択された１又は複数のルールセットは、前記ソース言語の１又は複数の文字に基づいて選択されることを特徴とする請求項１９に記載のシステム。
【請求項２１】
前記型チェッカはコンパイラの一部であることを特徴とする請求項１９に記載のシステム。
【請求項２２】
前記複数のルールセットそれぞれは、特定のソース言語に対応することを特徴とする請求項１９に記載のシステム。
【請求項２３】
前記複数のルールセットそれぞれは、特定の型チェック強度に対応することを特徴とする請求項１９に記載のシステム。
【請求項２４】
コンパイラにおいて型付き中間表現として表現されるソースコードを分析する方法であって、
前記型付き中間表現に基づいて異なるルールセットの中からルールセットを選択することと、
前記選択されたルールセットに基づいて前記型付き中間表現を分析することと
を備えることを特徴とする方法。
【請求項２５】
前記ルールセットを選択することは、編集処理における一連のステップのどのステップで前記型付き中間表現が生成されたかに基づくことを特徴とする請求項２４に記載の方法。
【請求項２６】
前記ルールセットを選択することは、前記型付き中間表現が生成されたソース言語に基づくことを特徴とする請求項２４に記載の方法。
【請求項２７】
前記ルールセットを選択することは、プロセッサアーキテクチャに基づくことを特徴とする請求項２４に記載の方法。
【請求項２８】
前記ルールセットを選択することは、前記型付き中間表現が、検証されたコードを表すか、検証されていないコードを表すかに基づくことを特徴とする請求項２４に記載の方法。
【請求項２９】
前記ルールセットを選択することは、前記型付き中間表現が、タイプセーフコードを表すか、タイプセーフでないコードを表すかに基づくことを特徴とする請求項２４に記載の方法。
【請求項３０】
前記ルールセットを選択することは、前記型付き中間表現が、型付きコードを表すか、型付きでないコードを表すかに基づくことを特徴とする請求項２４に記載の方法。
【請求項３１】
前記ルールセットを選択することは、前記型付き中間表現が、強く型付けされたコードを表すか、弱く型付けされたコードを表すかに基づくことを特徴とする請求項２４に記載の方法。
【請求項３２】
請求項２４に記載の方法を実行するためのコンピュータ実行可能な命令を含む、コンピュータ読み取り可能な記録媒体。
【請求項３３】
プログラミングインターフェースであって、
プログラムの中間表現の整合性をチェックするための複数のルールを構築する手段を備え、前記プログラムの中間表現の整合性をチェックすることは、動作可能な型チェッカに複数のルールを提供し、該複数のルールのうち、第１のセットを第１の中間表現に適用し、かつ、第２のセットを第２の中間表現に適用することを備えることを特徴とするプログラミングインターフェース。
【請求項３４】
請求項１に記載の方法を実行するためのコンピュータ実行可能な命令を含む、コンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、型システムに関し、詳細には、新しい及び更新されたプログラミング言語に拡張可能な型システムに関する。
【背景技術】
【０００２】
型システムは、実行時エラーの発見及び防止を支援するためのプログラミング言語に用いられるシステムである。プログラミング言語は、変数、関数等のオブジェクトを宣言する型のセットを含む場合に「型付けされ（ｔｙｐｅｄ）」、これらの型は、言語で書かれたプログラムの編集中に、ルールセットと対比してチェックされる。型付き言語で書かれたソースコードが型ルールのうちのひとつに違反している場合に、コンピュータエラーが確定する。
【０００３】
コンパイラで使用するために、型付き中間言語はここ何年かで研究団体における重要な研究を受けた。これによって、コンパイラの信頼性及び堅牢性が高められ、また、ガーベッジコレクションに必要な情報を追跡し及びチェックするための体系的な方法が提供される。その案は、付属する型を有し、かつ、ソースプログラムの型チェックと類似の方法で型チェック可能である中間表現を有するべきである。しかしながら、編集処理中に明確にされたアイテムを表現する型が必要であるため、型付き中間言語を実装する（ｉｍｐｌｅｍｅｎｔ）のはより難しい。
【０００４】
型付き中間言語が多くの異なる高水準プログラミング言語をさらに表現しなければならない場合には、型付き中間言語は実装するのがさらに難しくなる。異なる言語は、異なる原始動作及び型を有しているばかりでなく、高水準プログラミング言語は、異なる水準の型付けを有している。例えば、アセンブリ言語等のいくつかの言語は、一般に型付けされない。言い換えれば、それらは型システムを有していない。型付けされた言語のうち、いくつかのものは強く（ｓｔｒｏｎｇｌｙ）型付けされ、他のものはより緩く（ｌｏｏｓｅｌｙ）型付けされる。例えば、Ｃ＋＋は一般的に緩く型付けされた言語と考えられている一方、ＭＬ又はＰａｓｃａｌは強く型付けされた言語と考えられている。さらに、緩く型付けされたいくつかの言語は、より小さい言語のサブセットを有している。そのサブセットにより、プログラムの中の主要コードセクションが強く型付けされ、他のコードセクションが緩く型付けされることが可能となる。例えば、Ｃ＃、及び、．ＮＥＴ（ＭＳＩＬ）において使用されるマイクロソフト（登録商標）中間言語により、これが可能となる。このため、任意のこれらの高水準言語を表すために使用される型付き中間言語は、異なる型強度を表すことができなければならない。同様に、型付き中間言語の型システムは、型がチェックされるコード文字に依存する、異なるルールを実現することができなければならない。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
型付き中間言語が編集過程で低水準に移行した（ｌｏｗｅｒ）場合、別の問題が生じる。言語の低水準化は、プログラマが書くであろうもの等のより高い水準の形式から、中間言語等のより低い水準に、言語形式を変更する処理を参照する。さらに、言語は、中間言語から、マシーンに依存するネイティブコード等のコンピュータが実行するのに近い水準まで、より低水準化することが可能である。編集処理中に異なる水準に低められた中間言語の型をチェックするために、それぞれの表現のために異なるルールセットが使用されなければならない。
【０００６】
型付き中間言語を生成しようと試みることは、上述した問題を解決するのにはしばしば不十分である。例えば、Ｃｅｄｉｌｌａ  ＳｙｓｔｅｍのスペシャルＪコンパイラは、型付き中間言語を使用する。しかしながら、このコンパイラは、Ｊａｖａ（登録商標）ソース言語に固有のものであり、このため、例えば、型なしセイフコード（ｎｏｎ−ｔｙｐｅ−ｓａｆｅ−ｃｏｄｅ）を有している複数の言語を処理する必要がない。さらに、このコンピュータは型チェックのために１つのルールセットのみを使用するため、コンピュータを複数の編集水準のために使用することができない。研究団体においては、型付き中間言語はしばしばソース言語に極めて固有である傾向があり、型付き中間言語を多数の編集段階のために設計する（ｅｎｇｉｎｅｅｒ）（及び、型を設計（ｄｅｓｉｇｎ）する）ことが困難である。
【課題を解決するための手段】
【０００７】
型の表現、型チェッカ、方法及びコンパイラは、中間言語の様々な形式における整合性をチェックするために提供される。特に、型付き中間言語は、型付き及び型付きでない言語と、緩くかつ強く型が付いた言語と、ガーベッジコレクションを行う及び行わない言語とを含む、複数の（異種の）ソース言語で書かれたプログラム表現における使用に適切である。さらに、異なる型及び原始的な動作を有する新しい言語を扱うために、型チェックアーキテクチャを拡張することができる。型、型チェック、方法及びコンパイラは、様々な態様を含んでいる。様々な態様は、別々かつ独立に使用することができ、又は、様々な態様は、様々な組み合わせ及び副次的な組み合わせで使用することができる。
【０００８】
ひとつの態様として、コンパイラにおけるプログラミング言語の型チェックの方法が提供される。１又は複数のルールセットが型チェッカへの入力として選ばれ（ｔａｋｅ  ａｓ  ｉｎｐｕｔ  ｔｏ）、その型チェッカは、多数の基準のうちの、どれかひとつ、又は、複数の組み合わせに基づいて、１又は複数のルールセットを選択する。それらの中には、編集（ｃｏｍｐｉｌａｔｉｏｎ）段階、ソース言語、アーキテクチャ、及び、型チェックされた言語における現在の型水準が含まれる。選択された１又は複数のルールセットを用いて、その言語の型チェックが行われる。
【０００９】
他の態様として、コンパイラは、多数の基準のうちの、いずれか１つ、又は、１又は複数の組み合わせに基づいた、１又は複数のルールセットを構築する型チェッカとして提供される。ルールセットは、強い（ｓｔｒｏｎｇ）型チェックと対応する１つのルールセット、弱い（ｗｅａｋ）型チェックと対応する１つのルールセット、及び、表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）と対応する１つのルールセットを含むことが可能である。弱いルールセットは、型キャストを許容する等、型におけるさらなる柔軟性を許容するが、表現ルールセットは、中間プログラム表現の一部において落とされた型情報を許容する。
【００１０】
他の態様において、プログラムインターフェースは、プログラムの中間表現の整合性をチェックする複数のルールを構築するために提供される。中間表現の整合性をチェックすることは、予め定められた基準に基づいて、第１のルールセットを１つの中間表現に適用し、第２のルールセットを他の中間表現に適用する型チェッカに対して、複数のルールを提供することを含むことが可能である。
【００１１】
これらの及び他の態様は、添付図面を参照した後述する詳細な説明によって明らかになるであろう。
【発明を実施するための最良の形態】
【００１２】
中間言語の様々な形式の整合性をチェックするために、型表現、型チェッカ、コンパイラが提供される。型チェッカ及びコンパイラは、プログラムコンポーネント（要素）及び／又は編集段階のためのソース言語に依存して、異なる型及び型チェックルールの使用を許容する。例えば、様々な言語で書かれたプログラムに適用される高水準のオプティマイザ（最適化ツール）を有することが望ましい。これらの言語は、異なる原始的な型、及び、原始的な動作を有する可能性がある。例えば、１つの言語は、複雑な計算を含むことができる一方、他の言語は、コンピュータグラフィックに特有の型及び操作を含むことができる。中間表現を異なる型のシステムによってパラメータ化できるようにすることで、異なる原始型及び操作を有する言語のためにオプティマイザを用いることが可能である。他の例はあるプログラムを含むことが可能であり、そのプログラムは、あるコンポーネントが強い型付き言語のサブセットで書かれており、かつ、他のコンポーネントが完全な言語（ｆｕｌｌ  ｌａｎｇｕａｇｅ）で書かれているが、これはタイプセーフ（ｔｙｐｅ−ｓａｆｅ）ではない。第１のコンポーネントセットをチェックする、より多くのエラーを有することが望ましい。これは、異なるコンポーネントに対して異なる型チェックルールを使用することによって達成される。さらに、他の例として、編集中に落ちる型情報がある。初期の段階で正確な情報を保つように強制している間、型チェッカ及びコンパイラは、型情報を後の段階へと落とすようにすることが可能である。これは、異なる編集段階に対する異なる型チェックルールとの結合において、未知数型を使用することで達成可能である。
【００１３】
図１は、多くの異なるソース言語を表すための異なる低下した水準を有する、型付き中間言語を利用するシステムに対する一般的な編集処理である。ソースコード１００から１０６は、４つの異なるソース言語で書かれており、これらの４つの異なるソース言語は、型付けされ又は型付けされない可能性があり、異なる型強度水準を有する。例えば、Ｃ＃で書かれたソースコード１００は、Ｃ＋＋で書かれたソースコード１０６よりもより強く型付けされるであろう。ソースコードは、まずリーダ１０８によって処理され、システムに入力される。次に、ソース言語は、型付き中間言語のＨＬＲ（ｈｉｇｈ−ｌｅｖｅｌ  ｉｎｔｅｒｍｅｄｉａｔｅ  ｒｅｐｒｅｓｅｎｔａｔｉｏｎ；高水準中間表現）に変換される。次に、ブロック１１０では、状況に応じてＨＩＲを分析及び最適化することが可能である。次に、ＨＩＲは、型付き中間言語のＭＩＲ（ｍｉｄ−ｌｅｖｅｌ  ｉｎｔｅｒｍｅｄｉａｔｅ  ｒｅｐｒｅｓｅｎｔａｔｉｏｎ；中間水準中間表現）に変換される。この表現はＨＩＲよりも低いが、マシーンはいまだ独立している。この時点で、ブロック１１２に示すように、状況に応じてＭＩＲを分析及び最適化することが可能である。次に、ブロック１１４でのコード生成によって、ＭＩＲは、型付き中間言語のマシーンに依存するＬＩＲ（ｌｏｗ−ｌｅｖｅｌ  ｒｅｐｒｅｓｅｎｔａｔｉｏｎ；低水準表現）に変換される。次に、ブロック１１６において、ＬＩＲは状況に応じて分析及び最適化され、ブロック１１８においてエミッタに供給される。エミッタは、システムに読み込まれたオリジナルソースコードを表す多くの形式１２０−１２６のうちのひとつにおけるコードを出力するであろう。このプロセスを通じて、プロセスを完成するのに必要なデータは、永続性（ｐｅｒｓｉｓｔｅｎｔ）メモリ１２８に保存される。
【００１４】
従って、編集プロセスは、１つの水準の表現から他の水準の表現への中間言語命令の変換で構成される。例えば、図２は、マシーンに依存したＬＩＲへのＨＬＲの変換と共に、ＨＩＲへのソースコードステートメントの変換を示している。多数の高水準のプログラミング言語でソースコードステートメント２００を書くことが可能である。これらの言語は、容易に理解される方法でプログラマが読み書き可能なように設計されている。従って、プログラマは、「＋」等の文字を加算に使用することができ、ステートメント２００で示されるように、２つ以上のオペランドを加算する等、プログラマはより強力な形式を使用可能となる。
【００１５】
ステートメント２０２〜２０６は、同じ機能を表現するＨＩＲステートメント表現２００である。しかしながら、ステートメント２０２〜２０６は、コンピュータが理解できるが、依然としてアーキテクチャに依存しないフォーマットに近い。ステートメント２０２は、「ＡＤＤ」コマンドを使用して、第１又は第２の変数を加算し、結果を第１の一時的な変数ｔ１に代入する。次に、ステートメント２０４は、別の「ＡＤＤ」コマンドを使用して、ｔ１を第３の変数に加算し、結果を第２の一時的な変数ｔ２に代入する。次に、ステートメント２０６は、「ＡＳＳＩＧＮ」命令を使用して、ｔ２の値を結果変数ｚに代入する。
【００１６】
ステートメント２０８〜２１２は、ステートメント２０２〜２０６の中間言語のＬＩＲである。ステートメント２０８は、ｘ８６アーキテクチャに特有の加算命令を使用して、特定のレジスタに保存されている２つの変数の値を加算し、一時的な変数ｔ１に割り当てられているレジスタの中に結果を保存する。ステートメント２１０は、ｘ８６アーキテクチャに特有の加算命令を使用して、変数ｔ１と特定のレジスタに保存されている第３の変数と加算し、ｔ２に割り当てられている特定のレジスタ（ＥＡＸ）に結果を保存する。次に、ステートメント２１２は、ｘ８６アーキテクチャに特有の移動命令を使用して、ＥＡＸに保存されている値を出力変数ｚに移動する。
【００１７】
型チェックを実行するために、型付き中間言語は、明確又は不明確に表現された型表現を含む。明確な型表現は、表現において直接的に宣言される。例えば、ステートメント
ｉｎｔ  ａ；
は、明確に変数「ａ」を整数型として定義する。あるコードのステートメントについてのデフォルト型として定義することで、型表現を不明確に表現することも可能である。例えば、関数に対するデフォルトの戻り型が整数の場合、ステートメント
ｆ＿ｓｔａｒｔ（）；
は、引数を何も持たず、かつ、整数型の値を返す、関数ｆ＿ｓｔａｒｔを宣言する。
【００１８】
複数の表現水準での複数のプログラミング言語の使用に適した型付き中間言語についての型表現の一実施形態は、別表（Ａｐｐｅｎｄｉｘ）Ａに示されている。これは、多数のあり得る実施形態のほんの一例であることに留意されたい。
【００１９】
別表Ａに言及すると、多くの型表現が型クラス階層で定義されるため、様々な言語の型システムを型付き中間言語で表現することが可能である。抽象的な基本クラスは、全ての型について「Ｐｈｘ：：Ｔｙｐｅ」と定義される。例えば、基本クラスは、実際（ａｃｔｕａｌ）型、象徴（ｓｙｍｂｏｌｉｃ）型又は未知数（ｕｎｋｏｗｎ）（又は変数）型等の、様々な型に対する「ｓｉｚｅｋｉｎｄ」の中にサイズ情報を含むことが可能である。基本クラスは、型の分類を指定するために、「ｔｙｐｅｋｉｎｄ」も含むことも可能である。さらに、型付き中間言語からオリジナルのソースコードへのマッピングを提供するために、外部で定義された型をラップする（ｗｒａｐ）抽象型として外部型を提供することが可能である。
【００２０】
基本クラスの下では、「Ｐｈｘ：：ＰｔｒＴｙｐ」として定義されたクラスは、ポインタ型を表現することが可能である。同様に、様々なポインタを定義可能である。例えば、管理されたガーベッジコレクトポインタ（ｇａｒｂａｇｅ  ｃｏｌｌｅｃｔｅｄ  ｐｏｉｎｔｅｒ）（ガーベッジコレクトオブジェクトの範囲内の位置を指す）、管理されたノンガーベッジコレクトポインタ（ノンガーベッジコレクトオブジェクトの範囲内の位置を指す）、管理されていないポインタ（例えば、Ｃ＋＋で書かれたコードの中で見つけられる等）、参照ポインタ（ガーベッジコレクトオブジェクトのベースを指す）、及び、ナルがある。
【００２１】
階層における同じ水準において、「Ｐｈｘ：：ＣｏｎｔａｉｎｅｒＴｙｐｅ」として定義されるクラスは、内部のメンバーを含む型など、コンテイナ型を表すことが可能である。内部のメンバーは、フィールド、方法及び他の型を有することが可能である。「Ｐｈｘ：：ＦｕｎｃＴｙｐｅ」として定義されるクラスは、任意の必要な呼び出し仕様（ｃｏｎｖｅｎｔｉｏｎ）、引数のリスト及び戻り型のリストを含んだ、関数型を表すことが可能である。また、「Ｐｈｘ：：ＵｎｍｇｄＡｒｒａｙＴｙｐｅ」として定義されたクラスは、管理されない配列型を表すことも可能である。階層における「Ｐｈｘ：：ＣｏｎｔａｉｎｅｒＴｙｐｅ」の下では、さらに４つのクラスを定義可能である。「Ｐｈｘ：：ＣｌａｓｓＴｙｐｅ」として定義されるクラスはクラス型を表すことが可能であり、「Ｐｈｘ：：ＳｔｒｕｃｔＴｙｐｅ」として定義されるクラスは構造型を表すことが可能であり、「Ｐｈｘ：：ＩｎｔｅｒｆａｃｅＴｙｐｅ」として定義されるクラスはインターフェース型を表すことが可能であり、「Ｐｈｘ：：ＥｎｕｍＴｙｐｅ」として定義されるクラスは列挙型を表すことが可能である。階層における「Ｐｈｘ：：ＣｌａｓｓＴｙｐｅ」の下では、「Ｐｈｘ：：ＭｇｄＡｒｒａｙＴｙｐｅ」として定義される追加クラスは、管理される配列型を表すことが可能である。
【００２２】
別表Ａの中で示される表現において、クラス「ｐｒｉｍｔｙｐｅ」は、構造型の特別なインスタンスとして定義される。「ｐｒｉｍｔｙｐｅ」は、整数、浮動小数、未知数、虚数、条件コード、符号なし整数、ｘ整数（ｘｉｎｔ）等、様々な型を含むことが可能である。これらの表現は、型付き中間言語のＨＩＲ又はＬＩＲの両方で使用可能である。
【００２３】
さらに、目標とする特別な原始型を型表現に含むことが可能である。もし、型システムが汲み取る（ｍａｄｅ  ａｗａｒｅ  ｏｆ）ならば、いくつかの言語は、効果的に扱われることが可能な複雑な計算型を有する。「ＭＭＸ」命令を例にとる。このような命令は、マルチメディアデータ型及び通信データ型に対する単一の命令／複数のデータ操作をサポートするために、ｘ８６プロセッサのあるバージョンの中に構築される特別な命令セットのひとつである。型システムをカスタマイズして、型表現の最小限の交代でこれらの命令を認識し使用することが可能である。
【００２４】
別表Ａの中で示される型の型表現の実施形態には、「未知数」型も含まれる。この「未知数」型は、任意の型を表現することが可能であり、状況に応じて、それに関連するサイズを有する。サイズは、値のマシーン表現のサイズである。未知数型によって、コンパイラは、特定の型から未知数型へ型情報を変化させることによって、制御された方法で型情報を落とすことが可能となる。型が未知数であったとしても、未知数によって、コンパイラは、操作される値のサイズに依存するコードを生成することが可能となる。他の型は未知数型を使用することができ、このため、未知数型も、（いくつか、しかし、全てではない情報が知られている場合に）部分的に型情報の表現を許容する。
【００２５】
例えば、整数型へのポインタを想定する。低水準化したある段階では、型情報としての整数を落とすことが望ましい場合がある。未知数型によって、コンパイラは整数型を未知数型に置き換えることが可能となる。型チェッカは、関係（ｉｎｔｅｒｅｓｔ）のポインタが正しい型を指していることをチェックする必要がない。それは、実行時において、指し示されている値が、プログラム機能に不利に影響しないように扱われる機会を本質的に得る。
【００２６】
他の例として、関数型を定義するために未知数型を使用する。引数が前もって整数への型ポインタを有している場合、未知数への型ポインタの引数とともに関数が呼び出されると、コンパイラは正しい型が渡された（ｐａｓｓ）と信用しなければならない。ポインタの参照解除の結果として、整数であることが知られても知られなくてもよいが、しかしながら、その結果は整数として使用されるであろう。より複雑な例は、仮想関数呼び出しの高水準中間表現から低水準中間表現への変換中における、中間の一時的な変数の導入である。仮想テーブル（ｖテーブル）は、オブジェクト指向言語における仮想呼び出しを実現するために広く使用されている。低水準中間表現における仮想関数呼び出しを作成する最初のステップは、オブジェクトメモリの第１のフィールドにフェッチ（ｆｅｔｃｈ）することである。第１のフィールドはｖテーブルへのポインタを含んでいる。フェッチの結果は、一時的な変数に割り当てられる。一時的な変数型（ｖテーブルが多くのフィールドを保持することができる場合、ｖテーブルへのポインタを表現する型）を構築することは、表現するのに複雑で煩わしい場合がある。代わりに、コンパイラは、中間の一時的な変数「未知数への変数」を単に割り当てることができる。詳細な型情報を保つことが必要ない場合、又は、詳細な型情報を保つことがコンパイラの開発者にとって大きな負担となるかもしれない場合、このように、未知数型を使用することで編集の後の段階が単純になる。
【００２７】
図３は、編集の様々な段階で型付き中間言語の型チェックを行うための、ひいては、様々な低水準型付き中間言語の型チェックを行うための、コンパイラシステムの一実施形態を示している。ソースコード３００は、ソース言語の多様性のうちのいずれかひとつを表現している。ソースコード３００は型付き中間言語３０２のＨＬＲに変換される。その時に、ソース言語の型表現は型付き言語内部の型表現に変換される。
【００２８】
図１及び２に関して説明したように、ＨＩＲは編集処理を通じて低水準化される。この説明図の目的として、高い（ＨＩＲ）３０２、中間（ＭＩＲ）３０４、及び低い（ＬＩＲ）３０６水準表現が示されている。しかしながら、実施形態はこれに限定されない。任意の数の編集段階を型チェックすることができる。
【００２９】
型チェッカ３０８は、それぞれの水準表現での中間言語を型チェックすることができる。型チェッカ３０８は、編集処理のそれぞれの段階に、ひいては、中間言語のそれぞれの表現に、１又は複数のルールセット３１０を適用するためのアルゴリズム又は手順を実行する。ルールセット３１０は、ソース言語、編集段階、型付きの強度等、言語の特質（ｐｒｏｐｅｒｔｙ）を変えるために設計されたルールセットである。
【００３０】
例えば、ソースコード３００がＣ＋＋プログラミング言語で書かれたコードを含むと想定する。Ｃ＋＋ソースコード３００は、まず型付き言語のＨＩＲ３０２に変換される。必要なら、この時点で、型チェッカ３０８は特質の任意の数を決定するために、ＨＩＲ３０２と情報をやりとりすることが可能である。このような特質は、編集の段階（ＨＩＲ）、現在のソースコード型（Ｃ＋＋）、言語が型付けされているか否か（ｙｅｓ）、言語が緩く又は強く型付けされているか（ｌｏｏｓｌｙ）等を含むことができる。特質に基づいて、型チェッカは適切なルールセットを選択することが可能である。ルールが選択されると、型チェッカは、ルールセットに従ってＨＩＲの型チェックを行う。ＨＩＲがＭＩＲ又はＬＩＲに低水準化されると、特質は再びアクセスされ、同じ又は異なるルールセットが適合することができる。
【００３１】
一実施形態では、型チェッカは３セットの型チェックルールの提供を受けることが可能である。１つのセットは、Ｃ＃又はＭＳＩＬの型チェックに望ましい「強い」型チェックに対応することが可能である。他のセットは、「強い」型チェックよりも緩い型チェックを行う「弱い」型チェックに対応することが可能である。例えば、弱い型チェックルールセットは、型キャストを許可することが可能である。型キャストは、ひとつの型の変数が単一の用途のために他の型と同じ動作をさせられる場合をいう。例えば、整数型変数をｃｈａｒ（文字）と同じに動作させることが可能である。次のコードは、型キャストを用いて、文字「Ｐ」を印刷する。
ｉｎｔ  ａ；
ａ＝８０；
ｃｏｕｔ＜＜（ｃｈａｒ）ａ；
従って、「ａ」が整数型として定義され、値８０に割り当てられていたとしても、ｃｏｕｔステートメントは、型キャストのために変数「ａ」を文字型として扱い、従って、８０ではなく「Ｐ」（アスキー値８０）を表示する。
【００３２】
最後に、セットは「表現」チェックと対応することが可能である。「表現」チェックは、未知数を使用等することにより、中間プログラム表現の一部において落ちた型情報を許容することが可能であり、そのような型の情報を落とすことが可能な場合、又は、未知数型を別の型で置換可能な場合に、命令するルールを含むことが可能である。例えば、虚数型の値を返す関数の結果を、虚数型の変数に割り当てることを禁止することができる。
【００３３】
さらに、１セット以上のルールを編集の単一段階で使用することが可能である。例えば、ソースコード３００は単一の言語を含んでいるが、強く型付けがされている複数のセクション及び緩く型付けがされているいくつかのセクションを含んでいると想定する。タイプチェッカは、ある強く型付けされたセクションでのＨＬＲに対する１つのルールセット、及び、緩く型付けされたコードセクションに対する他のルールセットを使用することが可能である。
【００３４】
図４は、図３における説明と同じコンパイラシステム用の型チェッカのブロック図である。型チェッカ４００は、異なるソース言語及び／又は異なる編集段階と対応するルールセットの任意の数を、入力として受け取ることが可能である。図４において、４つのルールセット４０２〜４０８が型チェッカ４００に提供される。ルールセット４０２は、強く型付けされた言語のＨＩＲに対するルールセットを表し、ルールセット４０４は、弱く型付けされた言語のＨＩＲに対するルールセットを表し、ルールセット４０６は型が付けられていない言語のＨＩＲに対するルールセットを表し、ルールセット４０８はＬＩＲに対するルールセットを表す。プログラムモジュール４１０は、ＨＬＲにおいて強く型付された言語を表し、プログラムモジュール４１２は、ＬＩＲに低水準化された後のプログラムモジュール４１０を表す。
【００３５】
型チェッカ４００は、型チェックがなされたプログラムモジュールの特質に基づいて適切なルールセットを選択し、連携した手順又はアルゴリズムを使用して、選択されたルールをプログラムモジュールに適用する。例えば、型チェッカ４００は、（ＨＩＲにおいて強く型付けされた言語を表す）プログラムモジュール４１０の型をチェックするために、（強く型付けされた言語のＨＩＲのルールセットを表す）ルールセット４０２を選択することができる。続いて、型チェッカ４００は、（ＬＩＲにおいて強く型付けされた言語を表す）プログラムモジュール４１２の型をチェックするために、（ＬＩＲに対するルールセットを表す）ルールセット４０８を選択する。
【００３６】
図５は、型チェッカによって適用されるルールセットを選択するための手順の、一つのあり得る実施形態のフローチャートである。ブロック５００では、型チェッカはソースコードの型付き中間表現のセクションを読み込み、型チェックのためのルールを選択しなければならない。決定５０２は、型付き中間言語がＨＩＲ、ＭＩＲ、又は、ＬＩＲかを決定する。
【００３７】
ＨＩＲ又はＭＩＲである場合、決定５０４は、オリジナルソースコードが緩く又は強く型付けされているかを決定する処理を行う。緩く型付けされている場合、ブロック５０６は、弱い型チェックと対応するルールセットを選択する処理を行う。強く型付けがされている場合、ブロック５０８は、強い型チェックと対応するルールセットを選択する処理を行う。
【００３８】
型付き中間言語がＬＩＲの場合、決定ブロック５１０は、表現型チェックと対応するルールセットを選択する処理を行う。図５は単なる一実施形態であることに留意すべきである。異なる特質に対応して、及び、異なる特質に基づいて、ルールセットの任意の数を選択可能である。
【００３９】
説明した型チェックシステムのルールセットは、完全に新しい言語に、さらに、従来言語の新しい機能にも、容易に拡張される。例えば、新しい言語が導入されると、新しいルールセットは新しい言語のために容易に記述される。ルールセットは型チェッカ又はコンパイラシステム自体から分離され、ルールセットを分離されたエンティティとして受け入れるよう設計されるため、既存の型チェックシステム又はコンパイラを再分配又は更新することなく、新しい言語に対する新しいルールセットを分配することが可能となる。同様に、例えばＣ＋＋をサポートする追加ＸＭＬ等、新しい機能が既存の言語に追加された場合、編集の様々な段階でＣ＋＋に対応するルールセットを動的に容易に再構成し、新しい機能を扱うことが可能となる。この場合も、新しい中核のシステムを更新したり分配したりする必要はない。
【００４０】
ルールセットにより型編集を許容することも可能である。例えば、クラスが他から継承された場合に副次的な型付け（ｓｕｂ−ｔｙｐｉｎｇ）が特定の型に許容されるか否かを、ルールに記述される制約とすることができる。別の制約として、データをそのデータが含まれる仮想テーブルに変換可能であることの通知が所望される等の、箱詰めの（ｂｏｘｅｄ）制約があり得る。他には、サイズの制約、又は、同一の原始型の必要性を示す原始的な型制約を含むことができる。任意の他のルールセットの一部と同様に、新しい制約を所望のとおりに追加することが可能である。
【００４１】
ルールセットを記述するためのアプリケーションプログラミングインターフェースを介して、型チェッカによって使用されるルールセットを構築することが可能である。アプリケーションはルールを構築することが可能であり、ルールセットは、ルールが型付き中間言語の個々の命令に割り当てられている、原始型の階層で表される。特別なプログラムモジュール又は編集ユニットと関係のある様々な型の要素を明確に表現する型グラフの形式で、階層を供給することが可能である。シンボル及び操作等、ＩＲ要素は、型システムのエレメントと関連づけられるであろう。型グラフノードは、原始的な型及び構築された型と、これらの関係とを記述する。例えば、コンポーネント、ネスト型、関数署名（ｓｉｇｎａｔｕｒｅ）、インターフェース型、階層要素、及び、ソース名、モジュール／アセンブリの外部型要素への参照等の他の情報等がある。
【００４２】
シンプル型のルールの例は以下の通りである。
ＡＤＤ
Ｎ＝ａｄｄ  ｎ，ｎ
この例の目的として、Ｉが符号付整数型、Ｕが符号なし整数型、Ｘがどちらかの整数型、Ｆが浮動小数点、Ｎが以上のいずれでもあると想定する。図６は、これらの型の間の階層的な関係を示している。型Ｎは階層の頂点である。型Ｆ及びＸは、階層の後続の水準を形成するために、型Ｎから下方に分岐している（ｂｒａｎｃｈ  ｄｏｗｎ）。最後に、型Ｕ及びＩは、階層の最も低い水準を形成するために、Ｘ型から下方に分岐している。従って、「ＡＤＤ」という中間言語命令に対しては、このルールに従って、加算（ａｄｄ）命令が、Ｎ型又はより階層の低い型のみを実行することが可能であり、オペランドは階層において結果よりも高くなる必要はない。例えば、２つの整数を加算して整数を生成する（Ｉ＝ＡＤＤｉ，ｉ）ことが可能であるか、又は、整数及び浮動小数点を加算して浮動小数点を生成する（Ｆ＝ＡＤＤｉ，ｆ）ことが可能である。しかしながら、浮動小数点及び整数を加算して整数を生成する（Ｉ＝ＡＤＤｉ，ｆ）ことは不可能である。
【００４３】
階層として原始型を表現することにより、ルールセットを容易に変化させることが可能となる。過去において、型ルールは、ソースコードを使用してプログラムでしばしば表現されてきた。例えば、型チェッカは、型チェックルールを実行する多くのスイッチステートメントを含むことができる。従って、型チェッカのためにソースコードを修正するというルールの変更が要求された。しかしながら、階層ルールセットは、より容易に拡張性を提供する。上述したＡＤＤ命令のルールを考える。開発者が、例えば、型Ｃを混合型に加算したい場合、図７に示す階層の中で、Ｎ型の下でそれを容易に加算することが可能であり、ＡＤＤ命令のルールを所望の関数に変更する必要はない。
【００４４】
図８には、型チェックシステムにおいて型ルールに対する命令をチェックするための１つの方法が示されている。まず、ブロック８００において、構文的な命令のチェックの処理が行われる。従って、８０６における命令を考えると、型チェッカは、ＡＤＤ命令の型ルールに従って（例えば、この場合には、２つのソース表現と１つの送り先（ｄｅｓｔｉｎａｔｉｏｎ）の表現がある）、正確な数のソース及び送り先の表現が存在することを確実にする。それぞれの表現（及び副次的な表現）は、中間表現の中で明示（ｅｘｐｌｉｃｉｔ）型を有することができる。ブロック８０２においては、型チェッカは、ｅ１、ｅ２及びｆｏｏ（ｅ３）に対する明示型がＡＤＤ命令の型ルールに従っていることを、実際に検証する。ブロック８０４において、型チェッカは、必要ならば副次的な水準を超えて、型チェック命令を進める。例えば、型チェッカは、表現ｅ１、ｅ２、及びｆｏｏ（ｅ３）が明示型からなることをチェックすることが可能である。例えば、型チェッカは、ｆｏｏが関数型を有することをチェックすることができる。型チェッカは、関数型の結果型がｆｏｏ（ｅ３）の明示型と同じことをチェックすることができる。単一の引数型が存在し、ｅ３の型がその型に一致することを、型チェッカはさらにチェックすることができる。これによって、ｅ３への呼び出し型が型ルールと整合していることが保証される。
【００４５】
図９は、型チェックシステムの操作環境としての役目を果たすコンピュータシステムの例を示す。コンピュータシステムは、処理装置９２１と、システムメモリ９２２と、処理装置９２１へのシステムメモリを含む様々なシステムコンポーネントを相互接続するバス９２３とを含む、パーソナルコンピュータ９２０を含む。システムバスは、メモリバス又はメモリコントローラ、周辺バス、及び、少し例を挙げると、ＰＣＩ、ＶＥＳＡ、マイクロチャネル（ＭＣＡ）、ＩＳＡ及びＥＩＳＡ等のバスアーキテクチャを用いたローカルバスを含む、いくつかの種類のバス構成のうちのいずれかで構成することができる。システムメモリは、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）９２４、及び、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９２５を含む。起動時等にパーソナルコンピュータ９２０内の要素間の情報送信を支援する基本ルーチンを備えるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）９２６は、ＲＯＭ９２４に格納されている。パーソナルコンピュータ９２０は、リムーバブルディスク９２９及び例えばＣＤ−ＲＯＭディスク９３１を読むための光ディスクドライブ９３０を読み書きするために、又は、他の光媒体を読み書きするために、ハードディスクドライブ９２７、磁気ディスクドライブ９２８等をさらに含む。ハードディスクドライブ９２７、磁気ディスクドライブ９２８、及び、光ディスクドライブ９３０は、それぞれ、ハードディスクドライブインターフェース９３２、磁気ディスクドライブインターフェース９３３、光ディスクドライブインターフェース９３４によって、システムバス９２３に接続されている。ドライブ及びそれらに関連するコンピュータ読取可能な媒体は、不揮発性のデータ記憶装置、データ構造、コンピュータ実行可能な命令（動的リンクライブラリ、実行可能なファイル等のプログラムコード）等をパーソナルコンピュータ９２０に提供する。上述したコンピュータ読取可能な媒体の説明では、ハードディスク、リムーバブル磁気ディスク及びＣＤに言及したが、磁気カセット、フラッシュメモリカード、デジタルビデオデスク、ベルヌイカートリッジ等、コンピュータが読み取り可能な他の種類の媒体を含むことも可能である。
【００４６】
オペレーションシステム９３５と、１又は複数のアプリケーションプログラム９３６と、他のプログラムモジュール９３７と、プログラムデータ９３８とを含む、ドライブ及びＲＡＭ９２５に、多くのプログラムモジュールを格納することができる。ユーザは、キーボード９４０、及び、マウス９４２等のポインティングデバイスを介して、コマンド及び情報をパーソナルコンピュータ９２０に入力することができる。他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナ等を含むことができる。これらの及び他の入力デバイスは、しばしば、パラレルポート、ゲームポート又はＵＳＢ（ｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ）等の、システムバスに連結されたシリアルポートインターフェース９４６を介して、処理装置９２１に接続される。モニタ９４７又は他の種類のディスプレイデバイスも、ディスプレイコントローラ又はビデオアダプタ９４８等のインターフェースを介して、システムバス９２３に接続される。モニタに加えて、パーソナルコンピュータは、通常、スピーカ、プリンタ等の他の周辺出力装置（図示せず）を含む。
【００４７】
パーソナルコンピュータ９２０は、リモートコンピュータ９４９等の、１又は複数のリモートコンピュータへの論理的接続を使用して、ネットワーク環境において動作することができる。リモートコンピュータ９４９は、サーバ、ルータ、同等のデバイス又は他の一般的なネットワークノードであることができ、通常、パーソナルコンピュータ９２０に関連して記述される多くの又は全ての要素を含むが、図９にはメモリストレージデバイス９５０のみが示されている。図９に示される論理的接続は、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）９５１及びＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）９５２を含む。このようなネットワーク環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット及びインターネットにおいて一般的である。
【００４８】
ＬＡＮネットワーク環境において使用された場合、パーソナルコンピュータ９２０は、ネットワークインターフェース又はアダプタ９５３を介してローカルネットワーク９５１に接続される。ＷＡＮネットワーク環境で使用される場合、パーソナルコンピュータ９２０は、通常、インターネット等の、モデム９５４又はＷＡＮ９５２を介して通信を確立するための他の手段を含む。モデム９５４は、内部にあっても外部にあってもよいが、シリアルポートインターフェース９４６を介してシステムバス９２３に接続されている。ネットワーク環境において、パーソナルコンピュータ９２０又はその部分に関連づけて表されるプログラムモジュールを、遠隔記憶装置に格納することができる。示したネットワーク接続は例示に過ぎず、コンピュータ間の通信リンクを確立する他の手段を使用することができる。
【００４９】
実施形態の原理を図示し記述したが、当業者がその原理から離脱することなく構成及び詳細を変更することが可能なことは明らかであろう。
【００５０】
例えば、ここでの一実施形態では、型チェッカ又はコンパイラに供給可能な１又は複数のルールセットについて説明した。コンパイラ又は型チェッカが１又は複数のルールセットを選択し、言語及び／又は型チェックされている編集段階に基づいて言語の型チェックを行うと説明した。しかしながら、代わりに、型チェッカ又はコンパイラに１つのルールセットを供給し、言語及び／又は型チェックされている編集段階に基づいて、実行中に静的又は動的のいずれかで、型チェッカ又はコンパイラが１又は複数のルールのサブセットを構築することが可能である。
【００５１】
多くの可能性のある実施形態の観点では、示した実施形態は例示に過ぎず、本発明の範囲において限定ととらえるべきでないことがわかるであろう。むしろ、本発明は特許請求の範囲で定義される。従って、特許請求の範囲内に含まれるすべての実施形態を本発明として主張する。
【００５２】
【表１】
2007521567.tif 000002
【００５３】
【表２】
2007521567.tif 000003
【００５４】
【表３】
2007521567.tif 000004
【００５５】
【表４】
2007521567.tif 000005
【００５６】
【表５】
2007521567.tif 000006
【００５７】
【表６】
2007521567.tif 000007
【００５８】
【表７】
2007521567.tif 000008
【００５９】
【表８】
2007521567.tif 000009
【００６０】
【表９】
2007521567.tif 000010
【００６１】
【表１０】
2007521567.tif 000011
【００６２】
【表１１】
2007521567.tif 000012
【００６３】
【表１２】
2007521567.tif 000013
【００６４】
【表１３】
2007521567.tif 000014
【図面の簡単な説明】
【００６５】
【図１】一般的な編集処理のフロー図である。
【図２】高水準表現、及び、次に、マシーンに依存する低水準表現への、ソースコードステートメントの変換を示すテーブルリストである。
【図３】編集の様々な段階において型付き中間言語の型チェックのためのコンパイラシステムの一実施形態を示すデータフロー図である。
【図４】コンパイラシステム用の型チェッカのブロック図である。
【図５】型チェッカによって適用されるべきルールセットを選択するための１つの可能な手順のフローチャートである。
【図６】型間の階層的な関係を示す有向グラフダイアグラムである。
【図７】型間の階層的な関係に対する追加の型を示す有向グラフダイアグラムである。
【図８】型チェックシステムにおいて、型ルールに対する命令をチェックするための方法のフローチャートである。
【図９】型チェックシステムの実施形態のためのオペレーティング環境としての役割を果たすコンピュータシステムの例のブロック図である。
【図１】
2007521567.tif 000015
【図２】
2007521567.tif 000016
【図３】
2007521567.tif 000017
【図４】
2007521567.tif 000018
【図５】
2007521567.tif 000019
【図６】
2007521567.tif 000020
【図７】
2007521567.tif 000021
【図８】
2007521567.tif 000022
【図９】
2007521567.tif 000023
【国際調査報告】
2007521567.tif 000024