JP2009503677A - プログラムをデータオブジェクトとしてサポートするコンパイラ - Google Patents

Abstract

選択されたセマンティックオブジェクトがデータオブジェクトとして表現される言語をサポートするコンパイラを提供する。
データオブジェクトはプログラミング言語の能力を拡張するために多数の使い方が可能である。データオブジェクトはアプリケーションに渡され、そのアプリケーションのための実行可能命令を作成するために使用することができる。このようにすると、コンパイラのネイティブ言語で書かれた命令は、コンパイラのネイティブ言語と矛盾する言語のプログラムを受け付けるアプリケーションの制御のために使用することができる。コンパイラの構文検査(syntax checking)と変数バインディング(variable binding)能力は、コンパイラによって生成されたオブジェクトコードとは別のアプリケーションによって実行される命令のために使用することができる。データオブジェクトとして表現されたセマンティックオブジェクトは、ソースコードに含まれる明示的演算(express operations)に基づいて選択されることも、暗黙的型変換(implicit type conversion)に基づくこともある。

Description

本発明は、ソースコードファイル内の内部セマンティックオブジェクトをデータオブジェクトとして表現するコンパイラに関する。

場合によって、コンパイラプログラム命令をデータオブジェクトとして扱うことが望ましいことがある。この必要性は、例えば、コンピュータプログラマが別のアプリケーションのデータにアクセスするコンピュータプログラムを書いているときに起っている。例えば、あるプログラムをＣプログラミング言語で書いているプログラマは、ＳＱＬプログラミング言語で書かれたクエリ(query)に応答するデータベースにアクセスしたい場合がある。Ｃプログラムからデータベースにクエリするには、ＣプログラマはＳＱＬコマンドをストリングとしてＣプログラムに挿入することができる。Ｃコンパイラはストリングを実行可能コードに変換しない。むしろＣコンパイラは、プログラマによって入力された文字通りにそのストリングを格納する。

Ｃプログラムの実行時に、ストリングは、データベースのアプリケーションプログラミングインタフェース(application programming interface API)に渡される。ＡＰＩはストリングをコンパイルまたは解釈し、データベースへの望みのアクセスを行なうための適当なコマンドをデータベースに与える。

Lisp/Scheme、MetaML、およびTemplate-Haskelなどの言語のコンパイラは、コードがソースコードファイル内に明示的に引用符で囲まれていれば、ソースコードファイル内にそのコードを表現するデータオブジェクトも作成する。

本発明は、ソースコードファイル内の内部セマンティックオブジェクト(internal semantic object)をデータオブジェクトとして表現するコンパイラを提供することを課題にしている。多くの場合、セマンティックオブジェクト(semantic object)は、プログラム命令をソースコード形体で構成する式(expression)になっている。

一側面では、本発明は、コンパイラによって使用される構文(syntax)に従って内部セマンティックオブジェクトを処理して該データオブジェクトを外部セマンティックデータ構造(external semantic data structure)として作成することに関する。データオブジェクトは多数の使い方が可能である。データオブジェクトは、アプリケーションに実行させる式または関数を表現することもあり、そのアプリケーションに関数または式を実行させるためにそのアプリケーションに与えられることもある。別の側面では、本発明は、データオブジェクトとして表現するための内部セマンティックオブジェクトを自動的に選択することに関する。コンパイラは、ソースコードを表現するデータオブジェクトを受け取るように構成されたメソッドにパラメータとして渡される外部セマンティックデータ構造を、そのメソッドが受け取る引き数の型に基づいて、内部セマンティックオブジェクトから選択的に作成し、これにより暗黙的型変換(implicit type conversion)が行なわれるようにしている。

以上の概要説明は、請求項に明確化されている本発明を限定するものではない。

なお、添付図面は一定の比率で描かれたものではない。図面において、各図に図示されている同一またはほぼ同一の各コンポーネントは類似符号で示されている。明確化のために、すべての図面においてすべてのコンポーネントに符号が付けられているとは限らない。

自身がコンパイルするソースコードのセマンティックオブジェクトからデータオブジェクトを選択的に作成するコンパイラがあると、コンピュータ言語がよりフレキシブルになることはすでに認識されている。データオブジェクトは、コンパイルされるソースコード内在のセマンティックオブジェクトから、該セマンティックオブジェクトの構文データ表現を収めているデータオブジェクトへ、コンパイル時暗黙的型変換(compile-time implicit type conversion)を使用して作成されることがある。データオブジェクトは、ラベル、式、デリゲート(delegate)、メソッド、クラス、ステートメントブロックまたは他の任意の単位やソースコード命令をグループ化したものなどの、如何なる望みの形体の内部セマンティックオブジェクトに対しても作成される。以下の説明では、内部セマンティックオブジェクトの例としてコンピュータプログラム命令、特に式が使用されている。

暗黙的型変換(implicit type conversion)は、プログラマが所与のコンパイル時の型Ｔから（ランタイム時の）System.Typeインスタンスを取得できるようにする（Ｔ）構成体(construct)の型を一般化したものと見ることができる。しかし、データオブジェクトはなんらかの適当な方法で内部セマンティックオブジェクトから作成されることもある。

このようなコンパイラは、他のアプリケーションにアクセスするアプリケーションの開発を単純化することができる。セマンティックオブジェクトが、コンパイラのネイティブ言語以外のプログラミング言語の命令に応答するアプリケーションによって実行されることを目的としたコンピュータプログラム命令である場合に、そのアプリケーションにアクセスするコードが、そのプログラムの残りの部分と同じソースコード言語で書かれていることがある。さらに、暗黙的型変換によると、プログラマはコードの式を明示的に引用符で囲む必要がなくなる。

このようなコンパイラを使用すると、コンピュータプログラマは、アプリケーションへのアクセスを制御する命令をコンパイラのネイティブ言語で書くことができる。命令はそのネイティブ言語で書かれるので、コンパイラは、命令を単にストリングとしてストアする代わりにその命令を処理でき、これにより、コンパイラはコンパイル時に構文エラーを検出できるという利点が得られる。さらに、コンパイラは、他の場合にはプログラマによって手作業で行なわれていた名前バインディング(name binding)と変数キャプチャ(variable capture)とを行なうことができる。その結果、コンパイラの外部で利用可能なコンピュータプログラム命令を表現しているデータオブジェクトはそのホスト言語のセマンティックを反映することがあり、例えば、解決された変数名、チェックされた型またはホスト言語のセマンティックに従って挿入された変換を含んでいることがある。重要なことは、この処理はコンパイル時に行なうことができるので、単にストリングとして処理されたコードが実行されるときランタイム時に発生する可能性のあるエラーが減少することである。

このようなコンパイラが使用されるシステムの例として、図１はアプリケーション環境１００を簡略ブロック図で示している。アプリケーション環境１００は、WINDOWS（登録商標）オペレーティングシステムが稼動しているデスクトップコンピュータ上で作成されることがある。なお、この特定アプリケーション環境は本発明を限定するものではない。適切であれば、どのようなオペレーティングシステムでも使用が可能である。

さらに、適切であれば、どのようなハードウェアでもアプリケーション環境１００を構築するために使用できる。適切であれば、どのようなタイプの１または２以上のコンピュータを使用してもホストアプリケーション環境１００を構築することが可能であり、これらのコンピュータはスタンドアロンまたはネットワーキング構成で構成されていることがある。

WINDOWSindows（登録商標）オペレーティングシステムの下では、複数のアプリケーションがアプリケーション環境で実行されていることがある。図示の実施形態におけるアプリケーション環境１００では、コンパイラ１１０を含むアプリケーションとデータベースアプリケーション１５０が実行されている。従来と同じように、これらのアプリケーションの各々は、コンピュータ読み取り可能な記録媒体上にストアされたコンピュータ実行可能命令群から構成されていることがある。アプリケーション環境１００では、アプリケーションの関数を実行するようにこれらの命令が実行されていることがある。

コンパイラ１１０はソースコード１１２に作用する。ソースコード１１２は、アプリケーション環境１００を使用して一人または二人以上のプログラマによって開発されているプログラムを定義する複数のセマンティックオブジェクトを含んでいることがある。ソースコード１１２は都合のよい方法であれば、どのような方法でも作成されることがあり、アプリケーション環境１００に関連するコンピュータ読み取り可能な記録媒体上にストアされていることがある。例えば、人間のプログラマはキーボード（図示せず）からテキストをタイプし、それをアプリケーション環境１００に関連するファイルにストアすることでソースコードを作成することがある。

ソースコード１１２内のセマンティックオブジェクトは、人間のユーザによって開発中の望みのアプリケーションを定義することができる。図示の実施形態では、ソースコード１１２は、データベースアプリケーション１５０によって維持管理されているデータをストアし、リトリーブし、さもなければアクセスするアプリケーションを定義している。しかし、ソースコード１１２によって実現されたこの特定アプリケーションは本発明を限定するものではなく、ソースコード１１２は望みのアプリケーション用に準備されたプログラムを表わしている場合もある。

コンパイラ１１０は、ソースコード１１２内に収められたセマンティックオブジェクトに作用する。従来のコンパイラと同じように、コンパイラ１１０はソースコード１１２内のセマンティックオブジェクトを、オブジェクトコード１２０としてストアされたコンピュータ実行可能命令に変換することができる。ソースコード１１２と同じように、オブジェクトコード１２０も、アプリケーション環境１００に関連するコンピュータ読み取り可能な記録媒体に格納されていることがある。なお、オブジェクトコード１２０は、適切であればどのような方法でも、適切であればどのようなロケーションにでも格納しておくことができる。

オブジェクトコード１２０は、この例では、アプリケーション環境１００内で実行されるコンピュータアプリケーションを形成している。なお、オブジェクトコード１２０が実行されるロケーションは本発明を限定するものではない。オブジェクトコード１２０は、コンパイラ１１０が実行されている同じコンピュータ上で実行されることがある。これとネットワークで結ばれたコンピュータ上で実行されることもある。可能な変形の別の例として、オブジェクトコード１２０は、移動可能媒体上に記録されて、コンパイラ１１０が動作しているコンピュータに接続されていない複数のコンピュータに分散されることもある。

オブジェクトコード１２０を作成するほかに、コンパイラ１１０はソースコードファイル１１２内に収められたセマンティックオブジェクトを表現する１または２以上のデータオブジェクトも作成する。図示の実施形態では、データオブジェクトとして表現されたセマンティックオブジェクトは、コンパイラ１１０が作用するソースコード言語で書かれた式になっている。なお、以下では、このソースコード言語はコンパイラの「ネイティブ言語(native language)」と呼ぶことにする。ソースコードファイル１１２内に現れることがある式には、バイナリ式(binary expression)、単項式(unary expression)、３進式(ternary expression)、定数式(constant expression)、フィールドアクセス式(field access expression)、プロパティアクセス式(property access expression)、メソッドコール式(method call expression)、オブジェクト初期化式(object initializer expression)、オブジェクト作成式(object creating expression)、コレクションおよびアレイ初期化式(collection and array initializer expression)、アレイ作成式(array creation expression)、キャスト式(cast expression)、パラメータ参照式(parameter reference expression)、ラムダ式(lambda expression)、セマンティックツリー呼び出し式(invocation of semantic trees expression)、フリー変数キャプチャ式(free variable capture expression)または外部変数キャプチャ式(outer variable capture expression)がある。

データオブジェクトはコンパイラ１１０の外部で使用されることがあるが、コンパイラ１１０は、内部セマンティックオブジェクトからこれらのデータオブジェクトを作成するときそのネイティブ言語の構文ルールを適用することがある。例えば、コンパイラは、型チェック(type checking)、名前バインディング(name binding)、変数キャプチャ(variable capture)、多重定義解決(overload resolution)、エラーチェックまたはコンパイルされるプログラムとして内部で使用されるセマンティックオブジェクトの表現を作成する際に従来からコンパイラによって実行されている他の処理ステップを含む、１また２以上の演算(operation)を実行することがある。データオブジェクトはデータ構造に格納されることがあり、フィールドには、これらのコンパイラ演算の１つまたは２つ以上が内部セマンティックオブジェクトに適用されたときの結果を表わしているデータが収められている。このような構造はセマンティックデータ構造と呼ばれることがある。

アプリケーション環境１００では、内部セマンティックオブジェクトを表現するためにコンパイラ１１０によって作成されたデータオブジェクトの一部はコンパイラ１１０の外部で使用される。図１の例では、データオブジェクトはＡＰＩ１４０に渡され、内部セマンティックオブジェクトによって指定された演算を実行するためにデータベース１５０を制御する際に使用される。

以上のように、別のアプリケーションを制御することを目的としたソースコード命令が「引用符」で囲まれて、ストリングまたは他の文字通りの形体でアプリケーションに渡されていた従来技術とは対照的に、ソースコード命令を表現する外部データ構造が用意されている。図示の実施形態では、内部セマンティックオブジェクトは式であり、外部セマンティックデータ構造は式ツリー(expression tree)１３０になっている。式ツリー１３０は、アプリケーション環境１００に関連するコンピュータ読み取り可能な記録媒体にデータ構造としてストアされていることがある。図示の実施形態では、式ツリー１３０は、オブジェクトコードが実行されるコンピュータにアクセス可能であるコンピュータ読み取り可能な記録媒体上にストアされている。

各々の式ツリーは、一般的な形式 (generic form)でストアされていることがある。式ツリーを一般的な形式で格納すると、これらが使用される任意の特定コンテキスト用に容易にカスタマイズできるので、式ツリーを複数のコンテキストの中で使用することが可能になる。

コンパイラは、式または他のセマンティックオブジェクトの一般的な表現を、オブジェクトコードを形成するプロセスの一部として形成することがよくある。図示の実施形態では、式ツリー１３０は、式が処理されるときの式を表現するために従来公知なように、コンパイラが内部で使用する形式になっていることがある。なお、ここで説明している実施形態では、既存コンパイラとは異なり、選択されたセマンティックオブジェクトを表現しているデータ構造は、コンパイラ内部で処理するためにアクセスできるように、あるいはコンパイラの外部で処理するためにアクセスできるように格納されている。

図示の実施形態では、式ツリー１３０は、ソースコード１１２の命令によって指定された演算を実行するようにデータベースアプリケーション１５０を制御するために使用されることがある。ソースコード１１２からの命令を表現している式ツリーはＡＰＩ１４０に渡される。この例では、ＡＰＩ１４０はデータベースアプリケーション１５０へのアプリケーションプログラムインタフェースである。

ＡＰＩ１４０は、式ツリー１３０内に収められた式の一般的表現を、例えば、データベースアプリケーション１５０などによって実行されるフォーマットの命令に変換する。上述したように、公知コンパイラは、実行可能コードを形成する際の中間ステップとして式の表現を作成する部分を含んでいる。公知コンパイラは、式の一般的表現をデータベースアプリケーション１５０によって実行可能な形体の実行可能コードに変換する、第２部分を含んでいる。従って、ＡＰＩ１４０は、データベースアプリケーション１５０によって実行可能なフォーマットにコードをコンパイルする公知コンパイラ部分の機能に似ている。具体的例として、データベースアプリケーション１５０がＳＱＬクエリに応答する場合には、ＡＰＩ１４０は、現在公知であるか、将来開発されるかに関係なく、式の一般的表現をデータベースアプリケーションによって実行可能なコードに変換するためにＳＱＬコンパイラで使用されるテクノロジを使用して実現されていることがある。

一実施形態では、ソースコード１１２内のセマンティックオブジェクトのうち選択したサブセットだけが外部データ構造として表現されている。コンパイラ１１０は、ある種のセマンティックオブジェクトが外部データオブジェクトとして表現されるはずであることを示すソースコード１１２の構造体(construct)を認識するように作られていることがある。これらのセマンティックオブジェクトは、オブジェクトコード１２０を生成するためにこれらのセマンティックオブジェクトを使用する代わりに、あるいは使用することに加えて外部データ構造として表現することが可能である。

図１に図示の実施形態では、外部データ構造として表現されるように選択されたセマンティックオブジェクトは、アプリケーションに実行させる命令となるセマンティックオブジェクトである。コンパイラ１１０は、外部セマンティックデータ構造の中で表現されるセマンティックオブジェクトを特定する構造体をサポートしている。図２Ａから図２Ｂまでは、望みのデータ構造を生成するためにコンパイラ１１０を制御できる、ソースコードファイル１１２内の命令の構文を示している。図２Ａは、ソースコード形体の命令のシーケンスを収めているソースコード１１２の部分を示している。命令２１０、２１２および２１４は、命令がコンパイラ１１０によってどのような扱い方をされるかを示している。

命令２１０はデリゲート(delegate)Ｒの宣言である。このデリゲートＲは関数を参照するために使用される。デリゲートＲは、例えば、関数を指すポインタとして実現される。ここで説明している実施形態では、コンパイラ１１０はデリゲートＲのためのストレージスペースを割り当てるが、デリゲートＲのためのオブジェクトコードは生成しない。

命令２１２は関数ｆの宣言である。この例では、関数ｆは整数型(integer type)である引き数ｘを受け取り、ブール型(Boolean type)の値を戻してくる。戻される値は、引き数ｘの値が１０より大であるかどうかによって決まる。コンパイラ１１０は、引き数を処理するために必要な演算を実行するオブジェクトコードを作成し、戻される値を計算する。このコードは、関数ｆがコンピュータプログラム内の別の場所でコールされると実行される。

上記とは対照的に、命令２１４は式の宣言を表わしている。命令２１４は「Expression」のキーワードで始まり、これは、コンパイラ１１０に対して、式の引き数を表現している外部データ構造を作成するように指示する。この例では、式の引き数は関数ｆと同じ演算を実行する関数ｅを指定している。なお、コンパイラ１１０は、コンパイラが命令２１２を処理するとき作成されるオブジェクトコードではなく、命令２１４を処理するとき外部データ構造を作成する。

図２Ｂは、命令がデータオブジェクトを作成することを示している別の状況を示す図である。図２Ｂは、変数ｙとｚが定義されている命令２２０と２２２を示している。コンパイラ１１０は、変数ｙとｚの各々用のメモリロケーションを割り振り、これらのメモリロケーションを指定値に初期化するコンピュータ実行可能命令をオブジェクトコードに追加することにより命令２２０と２２２を処理することがある。

命令２２４は「Expression」のキーワードで始まり、これは、データオブジェクトがそこから作成される式をその命令が定義していることを知らせている。この例では、データオブジェクトによって表現される式からは、式ｘに対する引き数が変数ｙとｚの値の積より大であるかどうかを示すブール値が得られる。

命令２２４内に収められた式を表現する外部データ構造を準備するときに複雑さが発生している。式は、式の外側で定義され、ランタイム時引き数として用意されていない変数に作用し、そのような変数は「フリー変数(free variable)」または「外部変数(outer variable)」と呼ばれることがある。これらの変数の値はプログラムの実行中に変化することがある。従って、ここで説明している実施形態では、命令２２４の中の式を表わしているデータオブジェクトには、データオブジェクトの作成時に変数の値がロードされない。むしろ、データオブジェクトは情報への参照を含むように作成され、変数ｙとｚの現在値が得られるようにしている。同じような問題はある式が別の式を参照するときに発生している。第２式への該当参照は、第１式を表わしているデータ構造に含まれている必要がある。ある式から別の式への参照を実現する１つ方法は、ある外部セマンティックデータ構造の中に別の外部セマンティックデータ構造を参照するメカニズムを組み入れることである。

変数ｙとｚの値にアクセスするために必要な情報の表現が適切であれば、どのような表現でもデータオブジェクトに組み入れることができる。例えば、「funcletting」と名付けたプロセスが使用されることがある。Funclettingでは、コードの内側のフリー変数または部分式(sub-expression)をデータオブジェクトとしてキャプチャすることが行なわれる。フリー変数または部分式を表現する情報の基礎となる表現は、適切であればどのような形体にすることもできる。具体例として、データオブジェクトは、これらの値がストアされているメモリロケーションのアドレスを収めていることがある。メモリアドレスは絶対メモリアドレスであることも、スタックフレームまたは他のデータ構造までのオフセットであることもある。フリー変数または外部変数の値がどのように示されるかの別の例として、変数の値を戻してくる関数へのポインタが使用される場合がある。

Funclettingの使用は、図２Ｂに示すような方法で整数変数にアクセスすることに限定されない。他の型の変数への参照が行なわれることもある。

式内で使用される変数の値が式の実行時にどこから得られるかを示す情報を与えると、式を表現するデータ構造は、その実行時に望みの演算を実行する実行可能命令に即時に変換されることがある。望みの演算は、実行可能命令への変換がコンパイル時に行なわれるか、ランタイム時に行なわれるか、あるいはその中間で行なわれるかに関係なく、実行されることがある。さらに、望みの演算は、データオブジェクトから生成されたオブジェクトコードがいつ実行されるかに関係なく実行されることがある。

図３Ａを参照して説明すると、図は、ソースコード１１２内のセマンティックオブジェクトをストアするデータオブジェクト３１０の表現を示している。データオブジェクト３１０は、適切であればどのようなコンピュータ読み取り可能な記録媒体にも実現することができ、セマンティックオブジェクトを表現するのに適切な形体であれば、どのような形体にすることもできる。この例では、セマンティックオブジェクトはソースコード１１２の中で定義された式であり、データオブジェクトは式ツリーとして編成されている。式ツリーには複数のフィールドが含まれ、その各々には、式を評価するときに役立つ情報が収められている。式ツリーはこの分野で公知であり、コンパイラ１１０は、適切であればどのような方法でも、ソースコード１１２内の式から式ツリーを構築することができる。

この例では、式ツリーは、データフィールド３１２と３１４および演算フィールド３１６を含む、複数のフィールドで表わされている。データフィールド３１２と３１４にはデータがストアされることがあり、演算フィールドは３１６には、フィールド３１２と３１４内のデータに対して実行される演算のインジケータがストアされることがある。

データオブジェクト３１０は、別のデータフィールド３１８と別の演算フィールド３２０を含んでいる。演算フィールド３２０には、フィールド３１８内のデータに対して実行される演算のインジケータおよび演算フィールド３１６で示された演算の結果がストアされることがある。さらに、データオブジェクト３１０は結果フィールド３２２を含んでいる。結果フィールド３２２には、データオブジェクト３１０で表わされた式の評価結果をストアしておくロケーションが指定されていることがある。

図３Ａに示すように式ツリーを表わしているデータオブジェクト３１０は、データオブジェクトの一例である。適切であれば、どのような形体のデータオブジェクトでも使用されることがある。例えば、追加のフィールドが含まれていることがあるが、単純化のために図示されていない。例えば、データフィールドと演算フィールドはいくつでも使用されることがある。さらに、データオブジェクトはデータフィールドの数または演算フィールドの数を示すフィールドを含んでいることもあれば、式を表現するのに役立つフィールドを含んでいることもある。

図３Ｂを参照して説明すると、図は第２データオブジェクトを示している。データオブジェクト３５０は、データオブジェクト３１０と同じように、３５４と３５８のようにデータを指定するフィールドと３５６と３６０のようにそのデータに対して実行される演算を指定するフィールドを含んでいる。同様に、データオブジェクト３５０は、結果がどこに格納されるかを指定する結果フィールド３６０を含んでいる。データオブジェクト３５０がデータオブジェクト３１０と異なっている点は、データフィールド３５０には参照フィールド３５２が含まれていることである。この例では、参照フィールド３５２は、演算フィールド３５６で示された演算を実行するために使用されるデータがどこから得られるかを示すインジケータを含んでいる。参照フィールド３５２は、そこからデータが取得できる直接または間接メモリアドレスや他のインジケータを収めていることがある。例えば、参照フィールド３５２は該当データを検索する関数のアドレスを収めていることがある。

図３Ａと図３Ｂは、外部データ構造の実現例を示す図である。適切であれば、セマンティック式のどのような表現でも、式を表わすために使用されることがある。もっと一般的には、式や他の内部セマンティックオブジェクトを表現するために他のデータ構造が採用されることもある。

図４は、コンパイラ１１０がソースコード１１２をオブジェクトコード１２０および式ツリー１３０（図１）のような外部データ構造に変換するために動作するときのプロセスを示す図である。このプロセスはプロセスブロック４１０から開始する。ブロック４１０において、コンパイラは式を特定するためにソースコード１１２を構文解析(parse)する。ソースコードの構文解析はコンパイラでは公知のオペレーションである。ブロック４１０での処理は、それが現在公知であるか、将来開発されるかに関係なく、従来のコンパイラと同じように実行されてよい。

ある式がソースコード１１２から構文解析されると、その式の処理はブロック４１２から継続される。ブロック４１２において、コンパイラは式の構文を検査する。この構文検査はコンパイラの公知機能であり、ブロック４１２における処理は、それが現在公知であるか、将来開発されるかに関係なく、従来のコンパイラと同じように実行されてよい。構文検査では、ブロック４１０で特定された式を、コンパイラが処理する言語で許されている式を定義しているルールセットと比較することが行なわれる。例えば、コンパイラ１１０がＣプログラミング言語の変種で書かれたソースコードを処理する場合は、ブロック４１２で適用される構文ルールは、Ｃプログラミング言語の従来のルールが、ソースコード内の式に基づいてデータオブジェクトの作成または使用を定義しているルールで補強されたものが使用されることがある。例えば、従来の構文ルールは、命令２１４または２２４の中で使用されているような、「Expression」識別子の使用を許している構文定義ルールで補強されていることがある。他の従来の構文ルールは、式をデータオブジェクトとして表現すると可能にされる追加処理能力を反映するように改良された形体で使用されることもある。

ここで説明している実施形態では、ブロック４１２での構文検査はソースコード１１２内のすべての命令に適用され、その中には、最終的にアプリケーションプログラムに渡されて実行されるデータオブジェクトに変換されることを目的とした命令が含まれている。このようにすると、データベースアプリケーション１５０のような、アプリケーションプログラムによって実行されるように開発されたソードコードの中のエラーは、コンパイル時に検出することが可能になる。コンパイル時のエラー検出がしばしば望ましいとされるのは、ランタイム時のエラーが回避されるからである。

ブロック４１２で行なわれた構文検査で構文エラーが見つかったときは、プロセスはプロセスブロック４１４で指示されたエラー処理ルーチンに進むことがある。エラー処理ルーチンは、コンパイラ１１０の人間ユーザに構文エラーを通知する、エラーをログに記録する、構文エラーを自動的に訂正する、構文エラーのある式を処理中のソースコードから除去する、といった望みのアクションを実行することがある。

構文検査に続いて、処理はブロック４１３に進む。ブロック４１３において、式の中間表現が生成される。ソースコード式の中間表現を生成することはコンパイラの公知機能である。中間表現は、冗長式を除去する、変数および他のプログラムオブジェクトに必要なメモリ量を判断する、といったように、コンパイル中のプログラムでの種々の処理ステップを容易にするために使用されることが多い。多くの中間表現がコンパイラで使用されることは公知である。適切であれば、どのような中間表現でも使用されることがある。この例では、中間表現には、ソースコードの中の式を記述している式ツリーが含まれている。この例では、式を表現するように形成された外部セマンティックデータ構造は、コンパイラ１１０によって形成される式の中間表現と同じにすることができる。なお、外部セマンティックデータ構造とコンパイラによって内部で使用される中間表現は異なっていることがある。

プロセスは判定ブロック４１６に進む。判定ブロック４１６において、ブロック４１０で特定された式が、外部セマンティックデータ構造を残しておく必要のある式を表わしているかどうかのチェックが行なわれる。図２Ａと図２Ｂを参照して上述したように、「Expression」インジケータを使用する式には、オブジェクトコードではなく外部セマンティック構造が用意されている。もっと一般的には、データオブジェクトが生成されることを示す明示的演算がソースコードの中にあるか、あるいはデータオブジェクトが外部で使用されるとの暗黙的インジケータがある場合には、どのセマンティックオブジェクトにもデータオブジェクトが残されることがある。

外部データオブジェクトが式用に用意されるときは、処理はブロック４１８に進む。ブロック４１８において、式の中間表現を収めているデータオブジェクトが格納される。図４の例では、データオブジェクトの各々は式ツリーをストアするデータ構造である。なお、処理される式または他のセマンティックオブジェクトがどのような型であるかに応じて、適切であれば、どのような形体のデータオブジェクトでも採用されることがある。

そのあと、処理は判定ブロック４３０に進む。判定ブロック４３０において、ソースコード中に式が残っているかどうかのチェックが行なわれる。式が残っていれば、処理はブロック４１０に戻り、そこで次の式が構文解析される。そのあと、処理は特定された式から継続する。逆に、ソースコードの中に式が残っていなければ、図４のプロセスは終了する。その処理時に、特定された式からコードを生成させることが判定ブロック４１６で判断されたときは、処理は判定ブロック４２０に進む。判定ブロック４２０において、特定された式が、その式を実現するための実行可能コードが存在しないようなデータブロックとして表わされた式を使用しているかどうかのチェックが行なわれる。

ある式が先行式を参照し、データオブジェクトだけがその先行式の表現として利用可能であるときは、処理はブロック４２２に進む。ブロック４２２において、先行式を表わしているデータオブジェクトはそのデータオブジェクトからオブジェクトコードを生成するように処理される。そのあと、処理はブロック４２４に進み、そこで処理中の式に対してオブジェクトコードが生成される。生成されたコードには、処理中の式から直接に生成されたオブジェクトコードおよび先行式を表わしているデータオブジェクトから生成されたオブジェクトコードが含まれていることがある。

逆に、処理中の式が、実行可能コードがまだ生成されていない別の式を参照していないときは、処理はブロック４２４に進む。ブロック４２４において、オブジェクトコードがその式に対して生成される。

データオブジェクトのように、式の中間表現からオブジェクトコードを生成することはコンパイラの公知機能である。オブジェクトコードは、現在公知であるか、将来開発されるかに関係なく、従来のコンパイラで使用されている手法を用いてブロック４２２と４２４で生成されることがある。

オブジェクトコードがある式に対して生成されると、処理は判定ブロック４３０に進む。判定ブロック４３０において、ソースコード１１２に式が残っているかどうかのチェックが行なわれる。式が残っている場合は、処理はブロック４２０に戻り、追加の処理が行なわれる。式が残っていない場合は、プロセスは終了する。

図４は、コンパイラ１１０が動作するときの１つのプロセスを示している。コンパイラ１１０は他のプロセスステップを取り入れていることがあり、その中には、従来のコンパイラによって使用されているプロセスステップが含まれている。さらに、図４に図示のプロセスステップの実行順序は単なる例示である。プロセスステップは、適切であれば、どのような順序でも取り入れることができる。例えば、ソースコードファイル全体は、式が処理される前に構文解析されることがある。さらに、一部のプロセスステップはパラレルに取り入れられていることがある。

図２Ａと図２Ｂは、外部データ構造として表現されるべきセマンティックオブジェクトを特定する明示的演算がソードコード１１２に組み入れられていることを示している。コンパイラ１１０は、代替的にまたは付加的に、外部データ構造として表現されるべきセマンティックオブジェクトを他の方法を用いて特定することがある。いくつかの実施形態では、外部セマンティックデータ構造として表現されたセマンティックオブジェクトを、暗黙的型変換を用いて特定することが望ましいことがある。図５Ａ、図５Ｂおよび図５Ｃは、暗黙的型変換を用いる利点を示している。

図５Ａは、ＡＰＩの一部を実現できるコード断片(code fragment)５１２を示す図である。この例では、コード断片５１２は、ＡＰＩ１４０（図１）の一部になっている。コード断片５１２内の命令５２０は、ＡＰＩ１４０のメソッドが定義されるクラスを定義している。

コード断片５１２には、「Where」と名付けたメソッドを定義する命令５２２が含まれている。命令５２２で定義されたメソッドは引き数５２４をもっている。引き数５２４には型が関連付けられている。図５Ａの例では、引き数５２４は「Func」型が関連付けられている。命令５２２の中で定義されたメソッド「Where」がコールされたときは、このメソッドは「Func」型のパラメータを受け取るはずである。このようなパラメータは、例えば、デリゲート(delegate)として渡されることがある。

コード断片５１２の中で定義されたメソッドは本体５２６を含んでいる。本体５２６が実行されると、メソッド本体５２６内の引き数への参照の結果として、そのデリゲートがパラメータとして渡された関数に対応してコンパイラ１１０によって準備されたオブジェクトコードが実行される。

図５Ｂは、引き数がＡＰＩのメソッドに渡されるときの代替形体を示している。この例では、メソッドはデリゲート型が未認識である引き数内に定義されている。図５Ｂに図示のコード断片５４２では、命令５５０はＡＰＩのメソッドが定義されているクラスを定義している。命令５２２と同じように、命令５５２は「Where」と名付けたメソッドを定義している。命令５５２で定義されたメソッドも引き数を受け取る。図５Ｂの例では、引き数５５４は「Expression」構造体を使用している。この構造体の使用は、命令５５２で定義されたメソッドがコールされたとき、外部セマンティックデータ構造の形体の引き数が命令５５２に渡されることを示している。

命令５５２で定義されたメソッドはメソッド本体５５６を含んでいる。本体５５６が実行されると、引き数５５４がメソッド本体５５６内で参照されたとき、パラメータとして渡された外部セマンティックデータ構造がアクセスされる。メソッド本体５５６は、例えば、データベース１５０にアクセスするコマンドを生成するためにデータ構造を使用することがある。

図５Ａと図５Ｂは、ＡＰＩを開発しているプログラマが、そのＡＰＩによって実行される演算を示すパラメータをメソッドが受け取るときの異なるメカニズムを指定できることを示している。どちらのケースも、そのＡＰＩのユーザがソースコードプログラムを準備するとき、コンパイラ１１０のネイティブ言語を使用して望みの演算シーケンスを指定することができる。一方のケースでは、これらの命令はコンパイラ１１０によって実行可能オブジェクトコードに変換され、他方のケースでは、これらのソースコード命令はデータ構造に変換され、そのデータ構造はＡＰＩ１４０によってデータベース１５０に対するコマンドに変換される。ＡＰＩ内の各メソッドが該当型のパラメータを受け取ることを確かめる１つの方法は、コードがコールするメソッドの引き数に一致する型のパラメータを使用してＡＰＩ内のメソッドをコールするプログラムを、ＡＰＩのユーザに書かせることである。なお、ＡＰＩ１４０の各メソッドがそのソースコードの中の命令をどのように処理するかを、ソースコード１１２を開発するプログラマが理解しないで済むようにするために、暗黙的型変換がコンパイラ１１０に採用される。

図５Ｃは、暗黙的型変換が使用されるときソースコード１１２内に組み込まれることがあるコード断片５５２を示している。コード断片５５２はメソッド「Where」へのコールを行なう命令５６０を含んでいる。図５Ｃに示すように、命令５６０でコールされるメソッドは「Where」メソッドに渡されるパラメータとして式５６２を含んでいる。図５Ｃでは、コンパイラ１１０が式５６２をオブジェクトコードにコンパイルされる式として扱うか、外部セマンティックデータオブジェクトに変換される式として扱うかは、明示的に示されない。従って、メソッドをコールするプログラムを書くユーザは、どのような望みの方法でも式を指定することができる。それにもかかわらず、コンパイラ１１０は、式５６２を該当フォーマットで表現するために暗黙的型変換に頼ることがある。コンパイラ１１０は、コールされたメソッドが要求する引き数の型を解析し、式５６２を該当する型に変換することがある。例えば、命令５６０でコールされたメソッドが命令５２２（図５Ａ)内で定義された形体になっていれば、コンパイラ１１０は式５６２をオブジェクトコードに変換し、そのオブジェクトコードへのデリゲート(delegate)を、命令５６０でコールされたメソッドにパラメータとして渡すことがある。上記とは別に、命令５６０でコールされたメソッドが命令５５２（図５Ｂ）に示す形体で定義されている場合は、コンパイラ１１０は、式を外部セマンティックデータ構造に変換させることを、メソッドに渡された引き数の型から認識することがある。そのあと、その外部セマンティックデータ構造は、命令５６０でコールされたメソッドに渡されることがある。

暗黙的型変換によると、プログラマがソースコード１１２を生成するときの柔軟性が大幅に向上する。コンパイラ１１０は、外部セマンティックデータオブジェクトとして表現する該当命令を選択してＡＰＩ１４０に渡すので、プログラマは、ＡＰＩ１４０のメソッドごとに引き数の特定表現を知る必要がなく、データオブジェクトに渡される引き数を明示的に引用符で囲む負担から解放される。

以上、本発明の少なくとも１つの実施形態のいくつかの側面を説明してきたが、この分野の精通者ならば当然に理解されるように、種々の改変、変更、および改良は容易に行なうことができる。

例えば、上述したように、式の外側で指定された型をもつものとしてパラメータが特定されている式用に形成されたデータオブジェクトはそのパラメータの一般的表現を含んでいる。データオブジェクトのパラメータは、そのパラメータの型情報がある場合であっても、データオブジェクトの中で一般的に表現することが可能である。さらに、そのパラメータの型以外のセマンティックオブジェクトの他の側面は、データオブジェクトから実行可能コードを生成するために使用されるコンテキストから得られる特定情報と共に、データオブジェクトの中で一般的に表現されることがある。

また、データオブジェクトとして表現されることがあるセマンティックオブジェクトの例として式が使用された。メソッドやクラスのように、どのような望みのセマンティックオブジェクトでも、データオブジェクトとして表現されることがある。

このような改変、変更および改良は本明細書の一部となるものであり、本発明の精神と範囲内に属するものである。従って、上述した説明と図面は単なる例示である。本発明の上述した実施形態は多数の方法で実現することができる。例えば、これらの実施形態は、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアを組み合わせたもので実現されることがある。ソフトウェアで実現されるときは、ソフトウェアコードは、それがシングルコンピュータに用意されているか、複数のコンピュータ間に分散されているかに関係なく、適当であれば、どのようなコンピュータまたはコンピュータの集合上ででも実行させることができる。

また、概要を上述してきた種々のメソッドまたはプロセスは、種々のオペレーティングシステムまたはプラットフォームのいずれかを採用している１または２以上のプロセッサ上で実行可能なソフトウェアとしてコーディングされていることがある。さらに、そのようなソフトウェアは、いくつかの適当なプログラミング言語および／または従来のプログラミングまたはスクリプト記述(scripting)ツールのいずれかを使用して書かれていることがあり、実行可能マシン言語コードとしてコンパイルされていることもある。

この点に関して、本発明は、コンピュータ読み取り可能な記録媒体（または複数のコンピュータ読み取り可能な記録媒体）（例えば、コンピュータメモリ、１または２以上のフロッピディスク、コンパクトディスク、光ディスク、磁気テープなど）として実現されていることがあり、これらのコンピュータ読み取り可能な記録媒体には、１または２以上のコンピュータまたは他のプロセッサ上で実行されたとき、上述した本発明の種々実施形態を実現するメソッドを実行する１または２以上のプログラムが符号化されている。１または２以上のコンピュータ読み取り可能な記録媒体は、そこに格納されたプログラム（１または２以上）が１または２以上の異なるコンピュータまたは他のプロセッサ上にロードされて、上述した本発明の種々側面を実現できるように可搬的にすることができる。

本明細書において「プログラム」または「ソフトウェア」という用語は、上述した本発明の種々側面を実現するようにコンピュータまたは他のプロセッサをプログラミングするために採用できる任意タイプのコンピュータコードまたはコンピュータ実行可能命令セットを指すために広義の意味で使用されている。さらに、当然に理解されるように、本実施形態の一側面によれば、その実行時に本発明のメソッドを実行する１または２以上のコンピュータプログラムは、シングルコンピュータまたはプロセッサ上に置いておく必要がなく、複数の異なるコンピュータまたはプロセッサ間にモジュール方式で分散させて、本発明の種々側面を実現することが可能である。

コンピュータ実行可能命令は、プログラムモジュールのように、１または２以上のコンピュータまたは他のデバイスによって実行される多数の形体になっていることがある。一般的に、プログラムモジュールとしては、特定のタスクを実行し、あるいは特定の抽象データ型を実現するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などがある。代表例として、プログラムモジュールの機能は、種々の実施形態において望み通りに組み合わせることも、分散させることもできる。

上述した実施形態では、「オブジェクトコード」が説明されている。この用語も、コンパイルされたコードを指すために広義の意味で使用されることを目的としている。この用語には、実行可能ファイル、ＤＬＬを収めているファイルまたはコンパイラ出力の他の表現が含まれることもある。

さらに、「コンパイラ」という用語も広義の意味で使用され、「オブジェクトコード」が生成される時間は本発明を制限するものではない。例えば、コンパイラという用語には、「ジャストインタイム(Just In Time JIT)コンパイラまたはインタープリタとも呼ばれることがあるアプリケーションが含まれることもある。

さらに、「ファイル」という用語も論理的に関係のあるデータを指すために広義の意味で使用されている。この用語は、オペレーティングシステムによるデータのどのような特定の編成にも、記憶媒体上のどのような物理的位置にも制限されるものではない。

本発明の種々の側面は単独で使用されることも、組み合わせて使用されることも、あるいは上述してきた実施形態の中で具体的に説明されていない種々の構成で使用されることもあり、従って、上記説明の中で記述されている、あるいは図面に図示されているコンポーネントの明細と構成に適用されることに限定されない。例えば、ある実施形態で説明されている側面は、他の実施形態で説明されている側面とどのような方法でも組み合わせることが可能である。

「第１」、「第２」、「第３」などのように順序を示す用語が請求項の要素を修飾するために使用されているが、そのこと自体は、ある請求項の要素が他の請求項の要素に優先することも、先行することも、その順序も、あるいはメソッドのアクトが実行される時間的順序も意味するのではなく、これらは、ある名前をもつある請求項の要素を同じ名前をもつ別の要素と区別して（順序を示す用語を使用する場合を除く）、請求項の要素間を区別するラベルとして単に使用されたものである。

また、本明細書で使用されている語句と用語は説明目的のためであり、制限するものではない。「含む(including)」、「含む、備えた(comprising)」または「もつ(having)」、「収めている(containing)」、「を伴う(involving)」およびこれらの変形の使用は、そのあとに列挙された項目とその等価項目並びに追加項目を包含するものである。

コンパイラが使用されるアプリケーション環境を示す概略図である。 図１のコンパイラによって処理できるコードの断片を示す概略図である。 図１のコンパイラによって処理できるコードの断片を示す概略図である。 図２Ａと図２Ｂのプログラムセグメントの中の式を表現するために使用できるデータオブジェクトを示す概略図である。 図２Ａと図２Ｂのプログラムセグメントの中の式を表現するために使用できるデータオブジェクトを示す概略図である。 図１のコンパイラを動作させるプロセスを示すフローチャートである。 ＡＰＩの一部を実現できるコードの断片を示す概略図である。 ＡＰＩの一部を実現できるコードの断片を示す概略図である。 図５Ａまたは図５Ｂのどちらかに示すＡＰＩによって定義されたメソッドをコールできるコードの断片を示す概略図である。

Claims (20)

1. 複数の内部セマンティックオブジェクトをもつネイティブ言語のプログラムを、
   ａ）複数の内部セマンティックオブジェクトのうちの第１内部セマンティックオブジェクトをネイティブ言語の構文に従って処理して、前記内部セマンティックオブジェクトを表現する外部セマンティックデータ構造を作成するというアクト
   に従ってコンパイルするためのコンピュータ実行可能命令を格納したことを特徴とするコンピュータ読み取り可能な記録媒体。
2. 請求項１に記載のコンピュータ読み取り可能な記録媒体において、前記内部セマンティックオブジェクトは、ソースコードの形体のコンピュータプログラム命令を少なくとも１つ含むことを特徴とするコンピュータ読み取り可能な記録媒体。
3. 請求項１に記載のコンピュータ読み取り可能な記録媒体において、前記内部セマンティックオブジェクトはデリゲートを含むことを特徴とするコンピュータ読み取り可能な記録媒体。
4. 請求項１に記載のコンピュータ読み取り可能な記録媒体において、前記内部セマンティックオブジェクトはステートメントブロックを含むことを特徴とするコンピュータ読み取り可能な記録媒体。
5. 請求項１に記載のコンピュータ読み取り可能な記録媒体において、
   ｂ）暗黙的型変換に基づいて複数の内部セマンティックオブジェクトから内部セマンティックオブジェクトを選択するというアクト
   に従ってプログラムをコンパイルするためのコンピュータ実行命令をさらに含むことを含むことを特徴とするコンピュータ読み取り可能な記録媒体。
6. 請求項１に記載のコンピュータ読み取り可能な記録媒体において、
   ｂ）選択された内部セマンティックオブジェクトを特定するプログラム内の明示的演算に基づいて、複数の内部セマンティックオブジェクトから内部セマンティックオブジェクトを選択するというアクト
   に従ってプログラムをコンパイルするためのコンピュータ実行命令をさらに含むことを特徴とするコンピュータ読み取り可能な記録媒体。
7. 請求項６に記載のコンピュータ読み取り可能な記録媒体において、プログラムをコンパイルするための前記コンピュータ実行可能命令は、複数の式タイプの各々についてプログラム内の式を顕在化する外部セマンティックデータ構造を作成するコンピュータ実行可能命令をさらに含み、前記複数の式タイプは、バイナリ式、単項式、３進式、定数式、フィールドアクセス式、プロパティアクセス式、メソッドコール式、オブジェクト初期化式、オブジェクト作成式、コレクションおよびアレイ初期化式、アレイ作成式、キャスト式、パラメータ参照式、ラムダ式、セマンティックツリー呼び出し式、フリー変数キャプチャ式、および外部変数キャプチャ式を含むことを特徴とするコンピュータ読み取り可能な記録媒体。
8. 請求項１に記載のコンピュータ読み取り可能な記録媒体において、外部セマンティックデータ構造はセマンティック式ツリーによって表現されていることを特徴とするコンピュータ読み取り可能な記録媒体。
9. 請求項１に記載のコンピュータ読み取り可能な記録媒体において、第１外部セマンティックデータ構造は、第２外部セマンティックデータ構造への参照を含むことを特徴とするコンピュータ読み取り可能な記録媒体。
10. 請求項１に記載のコンピュータ読み取り可能な記録媒体において、前記外部セマンティックデータ構造は、フリー変数または外部変数への参照をキャプチャすることを特徴とするコンピュータ読み取り可能な記録媒体。
11. 引き数を有するメソッドをもつアプリケーションプログラムインタフェースを通してアプリケーションにアクセスするプログラムを準備するプロセスであって、前記引き数には型が関連付けられており、前記プログラムは前記メソッドへのコールをもち、前記コールにはパラメータが関連付けられており、前記プロセスは、前記パラメータを表現する外部セマンティックデータ構造を前記引き数の前記型に基づいて自動的および選択的に作成するステップを有することを特徴とするプロセス。
12. 請求項１１に記載のプロセスにおいて、外部セマンティックデータ構造を前記引き数の前記型に基づいて自動的および選択的に作成するステップは、該引き数が未認識のデリゲート型を有するとき、前記パラメータを表現する外部セマンティックデータ構造を選択的に作成することを含むことを特徴とするプロセス。
13. 請求項１１に記載のプロセスにおいて、コール引き数はソースコード形体のコンピュータプログラム命令を含むことを特徴とするプロセス。
14. 請求項１３に記載のプロセスにおいて、ランタイム時に、外部セマンティックデータ構造を使用してアプリケーションに対する少なくとも１つのコマンドを生成するステップをさらに含むことを特徴とするプロセス。
15. 請求項１４に記載のプロセスにおいて、前記外部セマンティックデータ構造を使用して少なくとも１つのコマンドを生成するアクトは、アプリケーションプログラムインタフェースによって実行されることを特徴とするプロセス。
16. 請求項１３に記載のプロセスにおいて、前記ソースコードは構文をもつ言語で書かれ、前記コール引き数を表現している外部セマンティックデータ構造を作成するステップは、前記コール引き数内で使用される変数の名前を前記構文に従ってバインディングするステップを含むことを特徴とするプロセス。
17. 請求項１３に記載のプロセスにおいて、前記ソースコードは構文をもつ言語で書かれ、前記コール引き数を表現している外部セマンティックデータ構造を作成するステップは、前記コール引き数内の前記コンピュータプログラム命令に構文エラーがないかどうかをチェックするステップを含むことを特徴とするプロセス。
18. 複数の式をもつプログラムを処理するためのコンピュータ実行可能モジュールを格納したコンピュータ読み取り可能な記録媒体であって、前記コンピュータ実行可能モジュールは、
    ａ）複数の式の中の１つの式を、その式について少なくとも１つのコンパイラ演算を実行することによってデータ構造に変換するコンパイラモジュールと、
    ｂ）前記データ構造を受け取り、前記データ構造から少なくとも１つのコマンドを作成するＡＰＩモジュールと、
    ｃ）前記少なくとも１つのコマンドを受け取り、前記少なくとも１つのコマンドによって指定された演算を実行するアプリケーションと、
    を含むことを特徴とするコンピュータ読み取り可能な記録媒体。
19. 請求項１８に記載のコンピュータ読み取り可能な記録媒体において、前記アプリケーションはデータベースを含むことを特徴とするコンピュータ読み取り可能な記録媒体。
20. 請求項１８に記載のコンピュータ読み取り可能な記録媒体において、前記コンパイラモジュールは、前記複数の式の中の第２式から第２データ構造を生成する部分と前記第２データ構造からオブジェクトコードを生成する部分とを含むことを特徴とするコンピュータ読み取り可能な記録媒体。

Images