目次へ    最終更新 : 2004/4/30

第8章 ダイナミック



 ダイナミック(Dynamic)は、CLEANの新しい実験的な特徴である。この概念を理解するのは容易だが、その実装はそう簡単ではない(VervoortとPlasmeijer,2002参照)。従って、全部を実装し、システムが完全に動作するには幾分時間がかかるだろう。待っていて欲しい。

 "ダイナミック"で何ができるのだろうか?容易で型安全な方法で、(異なった)CLEANアプリケーション間の式を保存し、交換することができる。式は、(未評価!)データと(未評価!)関数適用を持つことができる。ここのその使用例をいくつか示す。
 これら全てを可能にする為には、CLEAN言語にいくつかの特別な機能が必要である。しかし、CLEANの実行時システムの特別なサポートも必要である。この中には、動的型検査(dynamic type checking)動的型単一化(dynamic type unification)、任意のCLEAN式及び型の動的エンコード・デコード(dynamic encoding and decoding)動的連係(dynamic linking)、ディスク上の動的オブジェクトのガーベッジコレクション(garbage collection)ジァストインタイムなコード生成(just-in-time code generation)が含まれる。

 CLEAN 2.0では、動的型システム(dynamic type system)を加えたので、CLEANは現在では、静的型付き(static typing)動的型付き(dynamic typing)の両方を有する混合型システム(hybrid type system)を提供している。静的な型のオブジェクト(式)を包んで、動的な型のオブジェクト("Dynamic")にすることができるし、その逆も同様である。Dynamicの型は、実行時にのみ検査できる。アプリケーションは、複数のDynamicの型が、どの型がDynamicに正確に保存されるかを知る必要なく、互いに単一化できるかを検査することもできる。この方法では、CLEANアプリケーションは、プロセスとプラグインを管理する制御言語として使用できる(Van WeeldenとPlasmeijer, 2002参照)。

 本章では、まず、Dynamicがどのように構築できるのかを説明する(8.1参照)。セクション8.2では、Dynamicの型が、パターン照合を経由してどのように検査できるのか、そして、実行時型単一化を使用して、Dynamicが適合するのをどのように保証できるのかを説明する。

 セクション8.3では、独立に実行しているアプリケーション間の式を型安全に通信するのに、どのようにダイナミックを使用できるのかを説明する。セクション8.4では、これらを全て可能にするCLEAN実行時システムの基本的なアーキテクチャを説明する。意味的な制限と現在の実装に関する制限は、セクション8.5にまとめられている。


8.1 式をダイナミックに包む

 CLEANは強く型付けされた言語なので(5章参照)、CLEANの式は全てコンパイル時に決定される静的な型を有する。CLEANコンパイラは一般に、あらゆる式又はあらゆる関数の静的な型を推論できる。

 キーワードdynamicを使用することによって、(原則として)静的な型::τのあらゆる式を、静的な型::Dynamicである動的に型付けされたオブジェクトに変更できる。この"dynamic"は、元の式だけでなく、式の元の静的な型のエンコーディングも含むオブジェクト(正確にはレコード)である。式とその静的な型のエンコーディングの両方がダイナミックに包まれる。実行時には、ダイナミックの内容(式の値とそのエンコードされた型)を、動的パターン照合を経由して検査できる(8.2参照)。

 コンパイラは、式をその型と組合せてダイナミックにすることができるだけなので、エンコードされた型は実際にはそれに対応する包まれた式の型であることが保証される。しかし、通常のように、コンパイラが推論する型より特定された型を指定することが認められている。コンパイラは、そのような(制限された)型仕様の正当性を検査するだろう。多相型も保存できる。
 原則として(2、3の例外はある)、基本型、関数の型、ユーザー定義型、多相型、レコード型、配列の全ての型、リストの全ての型と存在量化型を含めて、あらゆる代数データ型をダイナミックに包むことができる。システムは、シノニム型も処理できる。制限は、抽象データ型、一意性型と多重定義関数を包む際に妥当する。以下のサブセクションを参照。

 キーワード"dynamic"で生成されたオブジェクトの静的な型は、定義済みの型Dynamicである。この方法で生成された全てのオブジェクトは、型Dynamicであり、コンパイラは一般に、Dynamicに隠された静的な型をこれ以上決定できないし、その型一貫性をこれ以上検査できない。Dynamicに保存される型は、実行時に検査されなければならない(8.2と8.3参照)。

8.1.1 抽象データ型を包む

 特定の型は単純に、根本的な理由から、Dynamicに包むことはできない。型Worldと型Fileのオブジェクトのような、現実世界に特別な意味のある定義済みの抽象型のオブジェクトがその例である。これらの型のオブジェクトをDynamicに包むのは健全ではない。というのも、これらの現実世界の対応物は、包んだり保存したりできないからである。
 これらの場合には、コンパイラ時エラーメッセージが与えられ、コンパイラは、式をDynamicに包むことを拒絶する。

 現在の実装では、Dynamicに包むことのできる型の種に関して、追加的な制限が存在する。現在のところ、抽象データ型をダイナミックに包むことは全くできない。その理由は、抽象型の等値性テストが簡単ではないということである。つまり、関連する型の定義の等値性をテストするだけでは十分でない。更に、これらの抽象データ型に関して定義されている演算が全く同じかどうかを検査しなければならない。これを行う最も直截な方法は、抽象データ型が同一モジュール(レポジトリ)から来ていることを必要とすることであろう。

8.1.2 多重定義関数を包む

 未実装:多重定義関数も、Dynamicに包むことができる。この場合、関数の追加的な辞書引数として、それに対応する型クラス(6.1参照)をDynamicに包む。Dynamicは、パターン照合で開包され、同一の型クラスが受信関数で定義されていなければならないが、そうでなければ、パターン照合は失敗する(8.2.2参照)。

8.1.3 一意型の式を包む

 未実装:一意型の式(9章)も、ダイナミックに包むことができる。しかし、実行時システムは、一意性型変数や型変換ステートメント(属性変数の不等式)を処理できない。型属性"*"のみを使用できる。更に、Dynamicに包まれる式の型に関する求めた一意性を明示的に定義しなければならない。そうでなければ、包まれた式の一意性は、保存されない。いつものように、コンパイラは、包まれた式の指定した型(一意性型属性を含む)が正当であるかを検査する。

8.1.4 未知の型の引数を包む

 コンパイラは、Dynamicに割当てられるべき具体型を、全ての場合において推論できるわけではない。例えば、多相関数が定義されている場合、実引数の型が何になるかは一般的には分からない。それが多相的であれば、それはどの型でもよい。
 任意の引数をDynamicに包むことのできる関数を定義したい場合、その引数の値だけでなく、具体的な静的型もその関数に渡されなければならない。効率性の理由から、全ての引数の型を全ての関数に渡すことは勿論したくない。従って、引数のどれがDynamicに包まれ得るのかを知らなければならない。特別なクラス文脈制限がこれを表現するのに使用される。従って、多相関数の代わりに、多重定義(6章参照)関数を定義しなければならない。クラスTC(Type Code)は、定義済みであり、未知の型の引数がダイナミックに包まれる場合にはいつでも、このクラスのインスタンスが必要とされる。コンパイラは、必要な場合には、TCの適切なインスタンスを自動的に生成するだろう。

8.1.5 動的型付けを使用して静的型システムを打ち負かす

 動的型付けはまた、静的型システムが禁止していることを行うのに使用できる。例えば、リストは、リストの全要素が同型であることを必要とする。全ての動的式は型Dynamicなので、静的な様々な型のオブジェクトをDynamicに変えることによって、これらを一つのリストに組み合わせることができる。

 全ての引数が動的に型付けされているCLEANプログラムを書くことができる。することはできるが、するのは良いことではない。つまり、ダイナミックを持つプログラムは、信頼性に劣るし(実行時型エラーが発生するかもしれない)、遥かに非効率である。

 Dynamicは、意図した目的、つまり、型安全な格納、取得及び、(独立した)アプリケーション間の任意式の通信に使用すべきである。


8.2 動的パターン照合を使用して、ダイナミックを開包する

 Dynamicが生成される場合(上記参照)、その静的な型は、型Dynamicである。コンパイラは一般に、Dynamicに包まれている式の元の型が何であるかを決めることはできない。それを理解する唯一の方法は、実行時に(この故にDynamicと呼ばれている)、パターン照合(3.2参照)又はcase構成物(3.4.2参照)を経由してダイナミックを調査することである。Dynamicに関するパターン照合によって、Dynamicに包まれた式のだけでなく、その元のも調査できる。従って、Dynamicによって、CLEANでは、実行時型検査と動的型単一化が可能である。そして、動的型システムの長所(より多くの式を型付けできる)と短所(型検査が実行時に失敗する恐れがある)を全て持つことになる。プログラマは、非照合の動的型によって、パターン照合が失敗する場合の処理に注意しなければならない。

 ダイナミックに包むことのできる式は、動的パターン照合を使用して開包することもできる。Dynamicに関するパターン照合によって、Dynamicの内容に関してケースの区別を作ることができる。実際のDynamicが型パターンで指定された値に照合すれば、それに対応した関数代替部が選択される。Dynamicが指定した型に照合するケースは分かっているので、静的型システムは、その知識を使用する。つまり、既知の型のダイナミックは、関数本体の通常の式として処理できる。この方法では、ダイナミックを通常の静的な型付けされた式に再び変換し戻すことができる。静的型チェッカーは、その知識を使用して、対応する関数代替部本体の型一貫性を検査する。

 警告:ダイナミックに関するパターン照合を定義する場合、パターン照合が失敗するかもしれないということを常に認識していなければならない。従って、非照合のダイナミックを処理できる代替部を常に含めることを勧める。そうでなければ、アプリケーションは、関数代替部のどれも照合しなかったというエラーメッセージを発して終了するだろう。

 Dynamicは、他のモジュールの関数が生成することができるし、他の(全く異なった)Cleanのアプリケーションから発生することさえ可能である(8.3参照)。従って、Dynamicでは、特定の名前を持つ型を保存することが可能だが、この型は、照合関数において分かっている型とは(若干又は全く)異なっている型定義を持っているかもしれない。従って、ダイナミックが包まれる文脈は、パターン照合を経由してダイナミックが開包される文脈とは全く異なっているかもしれない。従って、型構成子を照合して名前が一致するというだけではな十分ではない。つまり、それらは型定義も全く同一でなければならない。そうでなければ、照合は失敗するだろう。

 型定義(型構成子、データ構成子、クラス定義)の全てが、型変数の名前を除いて(α変換は認められる)構文的に同一である場合にのみ、2つの型は等しいとみなされる。型構成子の型の同等性は、これらが全く異なったCleanアプリケーションで定義されているとしても、Clean実行時システムが自動的に検査する。これを可能にする為には、Clean実行時システムのアーキテクチャ(8.4参照)を変更しなければならなかった。

 従って、ダイナミックに関するパターン照合が発生する場合、指示した順番に以下のことが検査される(case構成物は類似の方法で処理される)。
  1. 動的パターンで指定される(基本型、定義済み、ユーザー定義のどれかの)型構成子全ては、ダイナミックに保存されているそれに対応する実際の構成子の名前と比較される。対応型構成子が異なった名前ならば、パターン照合は失敗し、その次の代替部が試行される。
  2. パターン照合では、対応型構成子が同一名を持つ場合、実行時システムは、その型定義(その型は異なったCleanアプリケーション又はCleanモジュールで定義されていたかもしれない)も同一であるかを検査するだろう。システムは、これらの型定義を発見する方法を知っている(8.3と8.4参照)。定義が同一でない場合、その型は、異なっているとみなされる。パターン照合は失敗し、その次の代替部が試行される。
  3. 型が同一である場合、ダイナミックの無い標準的なパターン照合(3.2参照)で通常のように、その実際のデータ構成子(定数値)が、パターンで指定されたデータ構成子と比較される。指定した定数の全てが実際の値と照合すると、その照合は成功し、それに対応する関数代替部が選択される。そうでなければ、パターン照合は失敗し、その次の代替部が試行される。
 現在の実装では、Dynamicに包むことができ、従って、Dynamicから開包もできる型の種に関して、追加的な制限が存在する。

 動的パターン照合では、特定の型構成子(例えば、Tree Int)に関して照合するよう明示的に指定できる。型パターン変数(8.2.4参照)を使用して、実際の型が単一化されなければならない型スキームを指定することもできる。関数の型で定義されている多重定義変数(8.2.5参照)を使用することによって、関数が使用される静的な文脈は、受理されるダイナミックの種に影響を与えることができる。従って、型パターンで発生し得る変数には2つの特別な型がある。つまり、型パターン変数と多重定義型パターン変数である。

8.2.1 抽象データ型の開包

8.2.2 多重定義関数の開包

 未実装:動的パターン照合においては、型のクラス制限を指定できる。システムは、実際のダイナミックが、パターンで指定されるのと全く同じクラス文脈で実際に多重定義されている関数を持つかを検査する。型変数のα変換を除いて、関連する全てのクラス定義が構文上等しい場合、2つのクラス定義は等しいとみなされる。

8.2.3 一意型の式の開包

 未実装:一意型(9章参照)の式は、動的パターン照合を経由して開包もできる。しかし、実行時システムは、一意性型変数又は型変換ステートメント(属性変数不等式)を処理できない。型属性"*"を使用できるだけである。その照合は、指定した型が照合し、全ての型属性も照合する場合にのみ成功する。一意から非一意への変換又はその逆は発生しない。

8.2.4 型パターン変数を使用した型スキームの検査と単一化

 通常のパターン照合では、データ構成子(引数が特定の値かをテストする)と(定義域のどの具体値にも照合する)変数を使用できる。同様に、動的型のパターン照合では、型構成子(ダイナミックが特定の型の式を持つかをテストする)と(どの型にも照合する)型パターン変数を使用できる。しかし、通常の変数と型パターン変数との間には違いもある。関数定義の左手側で導入される通常の変数記号は全て、異なった名前を持たなければならない(3.2参照)。しかし、同一の型変数記号は、関数定義の左手側(そして勿論、右手側)で複数回使用できる。型パターン変数は、通用範囲が関数の代替部であり、動的型の文脈において、関数の右手側だけでなくパターンにおいても現れることができる。

 同一の型変数が左手側で使用される度に、パターン照合機構は、型変数とダイナミックに格納されている具体型を単一化しようと試みる。同一の型変数が左手側で複数回使用される場合、ダイナミックで全ての対応型に照合する最も汎用的な単一化子が決められる。汎用的な単一化子が見つからない場合、照合は失敗する。いつものように、全ての対応型構成子の中で、それらが実際に同じであるかが検査される。つまり、それに対応する型定義は、同等でなければならない(8.2参照)。照合している型構成子の型同等性は、その型が異なったCleanアプリケーションで定義されたものであるとしても、Clean実行時システムによって自動的に検査される。

 型パターン変数は非常に便利である。これは、特定の型スキームの検査又は異なったダイナミック間の内部型一貫性の検査に使用できる。しかし、検査する関数は、どの具体型が実際にダイナミックに格納されているかを正確には知らなくともよい。型パターン変数を使用して、柔軟な方法で、プラグインを管理・制御できる(8.3参照)。

 型パターン変数は、存在量化型変数(5.1.3参照)と似たように動作する。型パターン変数の実際の型が何であるかを静的に決定することはできない。従って、静的型システムでは、型が型パターン変数の値に依存している式を定義できない。静的型システムは、それを処理できない。というのも、その値を知らないからである。しかし、型が型パターン変数に割り当てられた型に依存している式ならば、再びダイナミックに包むことができる。というのも、これは実行時になされるからである。上のdynApplyの例を参照。
 注意:多相又は多重定義関数又は構成子を指示する、動的型に現れることのできる他の変数と、型パターン変数を混同しないように。前者は、型の全称量化子を経由して導入される。8.2.5も参照。

8.2.5 多重定義型変数を使用した未知の型の検査と単一化

 動的パターン照合では、Dynamicのどの型が要求されているのかを明示的に述べることができる。しかし、関数が使用されている静的文脈に、アクセスされるべきダイナミックへの制限を課させることも可能である。このことは、動的パターンの多重定義型変数(overloaded type variable)を使用することによって実現できる。この多重定義型変数は、関数それ自体の型の中に導入されなければならず、その変数は、文脈制限として、定義済み型クラスTC(8.1.1参照)を持たなければならない。このことによって、多重定義機構は、ダイナミックの中の要求された型が何でなければならないかを決めることができる(Marco Pil,1999で導入された"型依存関数(type dependent function)")。動的パターン内のこの多重定義型変数を使用することによって、静的多重定義機構によってこの変数に割り当てられる型が、動的パターン照合の必要な型の仕様として使用される。キャロット記号(^)は、型パターン変数ではなく多重定義型変数が使用されることを指示する為に、動的パターン照合の型パターン変数の接尾語として使用される。多重定義型変数は、通用範囲として、関数それ自体の型を含めた関数定義全体に及ぶ。

 注意:多重定義型変数を、型パターン変数又は、多相又は多重定義関数又は構成子を指示するのに動的型内で現れることのできるその他の変数と混同しないで欲しい。後者は、型内で、量化子を経由して導入される。


8.3 ダイナミックを使用した型安全な通信

 本章の導入で説明したように、Dynamicの最重要な実用例は、異なった(配布)CLEANアプリケーション間のデータとコードを型安全に通信できるということである。Dynamicが保存されるか通信される場合、それは文字列にエンコードされる(直列化される)。従って、原則として、ほとんどあらゆる通信媒体をDynamicの通信に使用できる。本セクションでは、Dynamicの保存・FileからのDynamicの取得方法のみを説明する。チャンネル又は送受信プリミティブを経由して直接にDynamicを通信することもできる。実際の機能は、CLEANライブラリが提供する能力に依存している。これは、本CLEAN言語報告の範囲外である。

 CLEANアプリケーションは、DynamicをFileに保存する場合、他の全ての(全く違う)CLEANアプリケーションは、そこからダイナミックを読込むことができる。Dynamicがデータだけでなくコード(未評価関数適用)も持つことができるので、このことは、あるCLEANプログラムのどの部分もまたある別のプログラムに嵌め込むことができるということを意味している。CLEANはコンパイルされたコードを使用しているので、このことは、実行時システムに高い影響を与える(8.4参照)。

 たった一回の関数呼出で、Dynamicを読み書きできる。CLEANライブラリStdDynamicでは、関数readDynamicとwriteDynamicが定義済みである。CLEANで通常のように、I/Oの実行には一意性型付けが使用される(9.1参照)。Dynamicが書込まれると、式全体(グラフ式とその静的な型)は、記号的にStringにエンコードされ、ディスクに保存される。Dynamicが読込まれると、式全体は遅延的に読込まれる。Dynamicの評価(パターン照合成功後にのみ発生し得る)が要求される場合にのみ、そのStringはDynamicにデコードされる。新規関数定義が嵌め込まれなければならない場合、自動的に行われる(8.4参照)。この遅延読込みは、Dynamicに保存されるダイナミックの為にも行われる。従って、Dynamicは、その型が動的パターン照合で承認される場合にのみ嵌め込むことができる。

 Dynamicの使用は、以下の例で示される。各例は、完全なCLEANアプリケーションである。


8.4 実装のアーキテクチャ

 上記例から、ディスクに保存されるDynamicは、データだけでなくコード(未評価関数と関数適用)も保持できることが分かる。この情報はどのようにしてファイルに保存され、実行中のCLEANアプリケーションにどのように新規データと新規機能を提供するのだろうか?これを理解するには、CLEANアプリケーションの生成方法についてもう少し知らなければならない。

ダイナミックの実装

 CELANアプリケーションは、インタプリタを経由して解釈されない。コンパイルされたマシンコードを使用して実行可能ファイルが生成される。Dynamicをディスクに保存し、それを再びディスクから取得するのは、単純にCLEANソースコードの(再)解釈によって行うことはできない。


 (CLEANで書かれている)CLEANコンパイラは、CLEAN実装モジュール(.iclと.dclファイル)を、マシン非依存のabcコード(.abcファイル)にコンパイルする。CLEAN定義モジュールは、個別にプログラムされたCLEANモジュール間の型一貫性を検査するのに使用される。abcコードは、仮想抽象マシンであるabcマシン(Plasmeijer and Van Eekelen,1993参照)のマシン命令を保持する。abcコードは、CLEAN用に特別に設計された、一種のプラットフォーム非依存バイトコードである。コードジェネレータ(Code Generator)(CLEANシステムにおいて、Cで書かれているたった1つのアプリケーション)は、abcコードをプラットフォーム依存なマシンコード(Windowsでは.objファイル)に翻訳する。コードジェネレータは、Intel(Windows,Linux)、Motorola(Mac)とSparc(Unix)のようなプロセッサ用の様々なプラットフォームのコードを生成できる。静的リンカ(Static Linker)(CLEANで書かれている)は、1つのCLEANプログラムのオブジェクトモジュールの全てを連係して、1つのクリック可能な実行可能アプリケーション(Windowsでは.exeファイル)にする。以上のコンパイルスキームは、ダイナミックがアプリケーション内部で使用される場合にさえ使用できる。しかし、DynamicがFileや別のプログラムと通信するとすぐに、様々な実行時のサポートが必要であるので、これを準備する為、伝統的なコンパイルスキームは変更される。


 変更後のコンパイルスキームでは、静的リンカは、アプリケーション(実際には、現在のところ.batファイルである)だけでなく、2つの追加的なファイルを生成する。1つは、コードレポジトリ(.libファイル)と呼ばれる。アプリケーションの全オブジェクトコードがここに集められる。もう1つのファイル(.typファイル)は、型定義を全て持つレポジトリである。レポジトリは、動的リンカ(Dynamic Linker)がアクセスするデータベースとして機能する。実行中のアプリケーションがプラグインのコードや検査されなければならない型を必要とする場合にはいつでも、動的リンカは、適切なレポジトリでそれを探す。CLEANプログラムが再コンパイルされる度に、新規のレポジトリが生成される。レポジトリを手動で消去してはならない。というのも、ディスクに保存されたDynamicが読込めなくなるかもしれないからである。非使用レポジトリを消去できる特別なカーベッジコレクタが提供されている。

 動的I/Oを行うCLEANアプリケーションを起動すると、特別なリンカ(CLEANで書かれた動的リンカ)も起動される(未起動ならば)。動的リンカは、コンピュータ上のサーバアプリケーションである。これは、Dynamicの読書きを行う、実行中の全てのCLEANプログラムのサーバである。動的リンカは、静的リンカがコンパイル時に従来のCLEANプログラムに行うのと同じ方法で、実行時にアプリケーション又はプラグインを構築する。コードが一度連係されれば、効率性に関するペナルティは無い。

 Dynamicが関数writeDynamicを使用してディスクに書かれる場合、2つ(!)のファイルが生成される。つまり、.dynファイルと.sysdynファイルである。.sysdynファイルは、実際の情報、つまりダイナミックのStringエンコーディングを保持する。このsysdynファイルは、動的リンカによって使用されるので、ユーザは触れてはならない。というのも、ディスクに保存されているDynamicが読込めなくなるかもしれないからである。提供される特別なガーベッジコレクタは、非使用.sysdynファイルも消去する。

 ユーザーは、.sysdynファイルに保存される実際のダイナミックへの参照を持つ.dynファイルに触れ、使用できるのみである。.dynファイルは、"型付けされた"ファイルと見ることができる。その他のユーザーファイルのように処理できる。何の危険も無く、改名したり移動したり削除したりできる。

 Dynamicがファイルに書込まれる場合、グラフとその型のエンコーディングがディスクに書込まれる。グラフが再び書込まれる場合に共有が維持されるという方法で、グラフがエンコードされる。保存されたグラフは、未評価関数を保持できる。ディスク上のDynamicでは、関数が、それに対応するコードレポジトリへの記号的ポインタによって表現される。ディスク上のダイナミックに格納される型は、型レポジトリに保存されるそれに対応する型定義を指し示す。

 その型が承認されない限り、プラグインは嵌め込まれない。ディスクに保存されたDynamicが(他の)アプリケーションによって読込まれる場合、保存されたDynamicへのポインタのみがまずCLEANプログラムで使用される。アプリケーションにDynamicを使用する為に、まず、パターン照合でそれを調べなければならない。パターン照合では、Dynamicの型は、指定された型又は別のDynamicの型に単一化される。実行時型単一化が成功した場合、動的リンカは、関連する型の全ての型定義も同一であるかを検査する。その型情報は、必要な場合にそれに対応する型レポジトリから取得される。型が同一で、従来のパターン照合も成功した場合、それに対応する関数本体が評価できる。保存されたDynamicの評価が要請される場合にのみ、ディスク上のダイナミックにおいてエンコードされたグラフが、必要な限り再構築される(Dynamicの中に入れ子されるDynamicは遅延的に再構築される)。動的リンカは、Dynamicに保存される未評価関数に対応するコードで連係する。これは、コードレポジトリから取得され、実行中(!)のアプリケーションにプラグインされる。動的リンカが、コードジェネレータに、必要なイメージ構築の為に新規コードの生成(ジャストインタイムなコード生成)を命令する場合がある。動的リンカは、異なったアプリケーションで定義された同一のデータ型が、実行時には実際に同型であるとみなされるような方法で連係されることを保証しなければならない。


8.5 ダイナミックに関する意味的制限

 ダイナミックは、CLEAN 2.0の実験的な特徴である。現行版では、依然として多くの制限と限界が存在する。

First Uploaded : April 8, 2004
Last Modified : April 30, 2004

Back