メインコンテンツまでスキップ

1. NILで導入される基本概念

1.1 NILの目的​

NILの2つの主な目的は次のとおりである。

  1. プログラムが実行される環境（その補完部分（its complement ））を記述すること。これには次の記述が含まれる。

    • データ形式とデータ構造
    • 入出力装置とのやり取り、およびそれらに期待される特性
    • オペレーティングシステムとのインタフェース

  2. 対話型システムのフロントエンド部分を表現すること。

    対話型システムを流れるデータ量は、一般に、データがシステムの核に近づくにつれて減少する。多くの対話型システムには、ユーザとの間で大量のデータをやり取りし、システムの残りの部分とはずっと少ないデータしかやり取りしない分離可能なモジュールが存在するか、あるいは定義できると仮定する。このモジュールをフロントエンド（Front-End）と呼ぶ。システムの応答時間が追加の伝送遅延の影響をできるだけ受けないことが重要である。また、ネットワーク上のデータレートをできるだけ低く保つことが望ましい。

フロントエンドの移転が、プログラムの移植性という問題全体を解決することを意味するわけではないと仮定する。

1.2 NILの下位区分​

S. Volansky [ ] が指摘したように、言語をその主な機能に対応するいくつかのサブ言語に分割すると都合がよい。そこでNILは次のように下位区分される。

  • 制御サブ言語
  • 演算サブ言語
  • データ宣言サブ言語
  • 環境サブ言語

1.2.1 制御サブ言語​

制御サブ言語は、計算がいつ（WHEN）行われるかを記述する。すなわち、制御の流れ、つまり計算の順序付けを記述する。言語の他のセクションに含まれる情報と合わせて、計算をどこで（WHERE）実行するかも記述する。

コンピュータネットワークは複数のシステム間に緩やかな接続をもたらすため、ネットワークマシンの制御言語は、高度な版においては、関係する時間遅延や資源割り当ての問題を考慮しつつ、利用可能なプロセッサに計算を割り当てられるべきである。この水準について検討することは、現時点では我々の目的ではない。

1.2.2 演算サブ言語​

演算サブ言語は、演算間の順序を示すことなく、データに対して行う演算を記述する。これは、演算がどのように（HOW）行われるかという問いに答えるものである。演算は2つのグループに下位区分される。

  • 計算グループ
  • データ操作グループ

後者はNILの最も重要な部分である。NILの主な目的はデータ構造とパターンの変換だからである。

1.2.3 データ宣言サブ言語​

データ宣言サブ言語は、演算の対象となる変数とデータ構造を宣言するために必要である。

ビード（bead）と呼ばれる原子的要素から構造を組み立てることができる。NILは「標準モード」で使われる標準のビード集合を提供する。「拡張モード」では、ユーザは新しいビードと、それらから成る新しい構造を定義できる。

1.2.4 環境サブ言語​

環境サブ言語は、プログラムが動作することを想定している文脈を表現する。すなわち、周辺装置に期待される特性や、特定のオペレーティングシステムを介した外部世界とのやり取りの意味論である。

したがって、完全な「プログラム記述子」は4つの別個のセクションを含む。

  • 環境セクション
  • データ宣言セクション
  • 制御セクション
  • 演算セクション

識別セクションは省略する。これは初期化手順のうちログインとソケット獲得の部分に相当するからである。

1.3 ネットワークマシン​

NILにおける基本的な概念の一つは抽象的なネットワークマシンの概念であり、これは次の特性を持つ。

  • 無限のメモリ：このマシンにはメモリ割り当てやガベージコレクションの問題は存在しない。しかし、項目はアクセス可能でなければならないため、やはりアドレスを持つ必要がある。

  • 可変語長：語は、理解可能かつアドレス指定可能なデータの最小項目とみなしてよい。ビードと呼ばれる原子的要素は、実際にはマシンの語である。各種のビードの構造と長さは、データ定義サブ言語で表現される。

図1.3.1に示すように、一つのHOSTは、2つのモードで動作しうるネットワークマシンとのみ通信する。

                                                  Network
   +--------+                                     Machine
   |  HOST  | <----------------------------------(
   +--------+

図 1.3.1

  • 標準モード：ビード、その構造、およびそれらに許される変換が標準であり、再定義する必要がない。標準のビードと構造はすべてのHOSTに知られている。

  • 拡張モード：標準のデータ定義と操作に加えて、あるいはその代わりに、HOSTが新しいビード、構造、変換を指定できる。拡張モードでは、ユーザは自分自身のマシンをネットワークマシンとして定義できる。これは、AnconaがRFC #42で提案したMY LOCAL、YOUR LOCALのモードと等価である。名前の定義が変更されていない場合は、標準の定義が仮定される。

データ定義サブ言語は、標準のビード集合を文書化する目的にも使われる。

ネットワークマシンの命令セットは、データ構造の大域的な変換を可能にする高い水準にある。

ネットワークマシンの環境は、サーバのHOSTの環境のうち、実行中のプログラムが使用する部分集合によって決まる。HOSTとネットワークマシンから成るシステムは、図1.3.2に示す2つの主な構成をとりうる。

   +----------+                     / Network
   |   user   | <------------------(  Machine
   |   HOST   |                     \ (server)
   +----------+

   Network                          +------------+
   Machine (user)  ---------------(  |   server   |
                                    |    HOST    |
                                    +------------+

  1. ネットワークマシンが、HOST（サーバHOST）の提供するプログラムのユーザとなる。

  2. HOSTマシンが、ネットワークマシンの提供するプログラムのユーザとなる。

    サーバマシンは、自身のハードウェア環境をユーザマシンに割り当てる。この選択は、プログラムを変更することなく遠隔から使えるようにするためのものである。遠隔プログラムのユーザが、自分自身と自分の環境をそれに適応させることになる。

    したがって、ネットワークマシンがサーバである場合、ネットワークマシンがデータ定義セクションと環境セクションを定義する。

図 1.3.2

1.4 実装​

データ定義サブ言語と環境定義サブ言語は、ネットワークマシン内のデータだけでなく、HOST内の環境とデータも記述できるべきである。究極的には、使用するデータ表現がデータ記述サブ言語で表現可能である限り、異なる言語で書かれた2つのプログラムが通信できるようにするべきである。

各HOSTには「ジェネレータ」が実装される。ジェネレータは、HOSTのデータ構造と環境を記述する規則を受け取り、それらをネットワークマシンの形式に変換する適切なトランスレータを生成する。これを図1.4.1に示す。

   HOST description      Network Machine
                        (description
                         non standard mode)        +---------------------+
                                                   | Network Machine     |
                                                   | standard mode       |
                                                   +---------------------+
             |                                                 |
             v                                                 |
      +-------------+                                          |
      |  GENERATOR  |                                          |
      +-------------+                                          |
             |                                                 |
             v                                                 |
  Data in +--------------+   Data is                           |
  HOST    |  TRANSLATOR  |   Network Machine                   |
  format  +--------------+   format                           |
             |                                                 |
             +-------------------------------------------------+

図 1.4.1

ネットワークマシンの標準が確定したら、マイクロプログラム方式の装置を用いてトランスレータをエミュレートすることを検討する価値があると思われる。この装置はHostに、あるいはむしろIMP"に追加され、それによって、ビット水準での長時間の操作を伴いうる変換の負荷を回避できる（図1.4.2）。

   +--------+            +--------+                /  Network
   |  HOST  | <----------|  HOST  | <-------------(   Machine
   +--------+            +--------+                \

図 1.4.2