Telescript (プログラミング言語)

**Telescript**は、General Magicによって開発されたOS, Magic Cap全体を成す機能の1つであり、エージェント指向のプログラミング言語である。Telescriptというプログラミング言語は、High Telescriptとして知られる修正されたCライク構文を使用し、実行のためにLow Telescriptと呼ばれるスタックベースの言語にコンパイルされる。Low Telescriptはホストコンピューター上の仮想マシンインタプリタ、すなわち 「Telescriptエンジン 」の中で実行される。

Telescriptの基本モデルは、後年リリースされたJavaが参考にしたものだが、アプリケーションが実行される場所が異なる。Javaでは、Javaアプリケーションを任意のプラットフォームにダウンロードし、ローカルで実行するようモデル化された（Java Servletもあるが）。一方、Telescriptでは本質的にこれと逆で、エンドユーザ機器がTelescriptプログラムをサーバにアップロードし、サーバ側の性能や機能を利用できるようにしていた。Telescriptでは、実行中のプログラムを移行することもできる。この言語には、プログラムのコードとシリアル化された状態をマーシャリング（連携動作や相互運用できるようにする）し、実行を継続するために別のTelescriptエンジン（デバイスまたはサーバ上）に転送し、最後に元のクライアントまたはサーバといったデバイスに戻って出力を提供する機能が含まれる。

General Magicは元々はApple社内のチームとして発足し、1990年にスピンオフで出来た企業である。1992年にマスコミで話題にされ始めたとき、AppleはNewton Messagepadで同じ市場に参入することを決定した。General Magicはニッチ市場を見つけることができず、Telescriptサービスは廃止され、携帯情報端末とは関係のない新製品が支持された。

2025年に発表されたGoogleの*[https://cloud.google.com/blog/ja/products/ai-machine-learning/a2a-a-new-era-of-agent-interoperability Agent2Agent プロトコル]*は類似性を指摘されている。

## 歴史
1990年、マーク・ポラットは、当時のApple CEOジョン・スカリーを説得し、コンピューティングの未来はパーソナルコンピュータではなく、コンピューティングパワー、通信システム、およびネットワークアクセス可能なサーバにあるデータを組み合わせたはるかに小さな携帯デバイスにあると確信させた。彼は、携帯デバイスは、接続するサーバよりも常にパワーが少ないことを指摘し、それを前提とした設計を提案した。デスクトップシステムのタスクを実行可能な携帯デバイスを構築する代わりに、携帯デバイスは、同様の結果を生み出すためにサーバの計算能力を目に見えない形で使用する必要がある。

スカリーは、ポラットにコードネーム“Pocket Crystal”の概念研究開始を許可した。初期チームの主要メンバーは、ポラットと、ビル・アトキンソン、アンディ・ハーツフェルドという有名な初代Macintosh開発者たちだった。チームはすぐにApple上層部に無視され、リソース確保に苦労し続けた。彼らは、Pocket Crystalを別の会社としてスピンオフするというアイデアで、再びスカリーにアプローチした。スカリーは同意し、ハードウェアの製造・販売で新しいパートナーを迎えるというアイデアにも同意した。新会社General Magicは、Apple、ソニー、モトローラがそれぞれ10%の株式を保有し1990年5月に設立された。ジョアンナ・ホフマン、スーザン・ケア、ダン・ウィンクラー、ブルース・リーク、フィル・ゴールドマンなど、初代Macintosh開発メンバーで、会社は構成された。

1992年までに、GMは、ソニー、モトローラ、松下電器、フィリップス、ブリティッシュテレコム、AT&Tコーポレーションなど、　Magic Cap環境に協力する多くの企業と開発契約を締結した。これはかなりの報道の「話題」を生み出した。Appleはこの時までにNewtonプロジェクトを開始し、初期はフルサイズのiPadに似たより大きなハンドヘルドタブレットのようなコンピュータの設計であった。General Magicのプレスでの成功により、彼らはNewtonを同じ携帯デバイス市場へ再配置し、1993年にリリースするよう急いだ。AppleはGeneral Magicの株式を売却し、彼らを訴えた。General Magicのパートナー各社は1994年までハードウェアをリリースできなかった。その頃には、Newtonの方はパーソナルデジタルアシスタント（PDA）がどうあるべきかを本質的に定義し、PDAシステムは手書き認識能力で判断された。Magic Capは手書きではなくポイント&クリックインターフェースだった（HyperCardや後のiPhone/iOSが似ている）。

1995年には、General Magicはかつての面影を失い、当初の開発者のほとんどが去っていた。1996年、引き継ぐためにスティーブ・マークマンが雇われ、彼はケビン・スレースを雇って会社を新しい方向に導いた。新しいチームは、OnStarの基盤として今日も存在する、Portico電話ベースのパーソナルアシスタントシステムを開発した。元のハンドヘルドグループは、1998年にDataRover Mobile Systems Incorporatedとしてスピンオフされ、2000年にIcrasに改名した。2001年に閉鎖される前に、多くの垂直市場にサービスを提供した。元の会社の残骸は2004年に清算された。

## 概説

### 基礎的な概念
Telescriptは、Telescriptクラウドをホストするサーバクラスタで実行される。そこでコンピューティングサービスと対話する*[[モバイルエージェント|エージェント]]* である小さなプログラムの概念モデルを元に開発された。ユーザの携帯デバイスは、限られた性能でもTelescriptを実行できる。このモデルは、ほとんどの情報とサービスが、AT&Tなどの通信プロバイダによってホストされるより大きなサーバで実行されると仮定した。 初期の文書から、これはクラウドで実行されていると言及している。 ユーザ向けプログラムは、そのようなエージェント群で構成され、ローカル、プロバイダのホスト、またはサードパーティのサーバに転送される。通信を調整するために、Telescriptには、ユーザを一意に識別する*telename*と、ネットワーク間を移動してもデバイスを識別する*teleaddressesの*概念も含まれていた。

例えとして、ユーザが購入したい新しいバーベキューグリルの価格を見つけるように依頼するショッピングアプリケーションを考えてみる。従来のクライアントサーバモデルでは、アプリケーションは多数のクエリを形成し、それらを多数のサービスに送信し、結果を収集して表示する。Telescriptモデルでは、アプリケーションは代わりに、リクエストからのデータで入力された新しいエージェントを構築し、名前とアドレスをスタンプし、それを処理のためにサーバ上のストアプレイスに送信する。その後、そのサーバはリクエストを直接処理するか、エージェントを実際のベンダーの場所などの他の場所に引き渡して、さらに処理をすることができる。結果をエージェントの内部データフィールドに配置し、ネットワークを介してユーザのデバイスに送り返すか、新しい「メッセンジャー」エージェントが生成して結果データのみを運び、ネットワークデータ転送を最小限に抑えるために送り返すことができる。

また、このモデルは、対話プログラムがデータ交換を行う方法として、従来のソリューションとは異なる。例えば、ユーザが前回の検索で見つけたバーベキューグリルを購入することを選択した場合、従来のシステムでは注文フォームに記入して支払いを確認するタスクは、ユーザデバイスとリモートサーバ間の直接通信を通じて達成されるため、プロセス全体を通して常に通信出来ることが必要である。Telescriptモデルでは、購入を完了するために必要な情報を持つ新しいエージェントが、そのベンダーのストアプレイスに送信され、ストアプレイスまたはベンダーのエージェントとやり取りし、成功または失敗で返答する。主な通信はエージェントとリモートサーバ間で行われるため、ネットワークを介した通信はプロセスの開始時と終了時にのみ必要である。

Telescriptはオブジェクト指向（OO）であり、オブジェクトの状態と通信の説明に、幾多の珍しい用語を使用した。属性は、他の言語がインスタンス変数またはフィールドと呼ぶものに対応する。メソッド呼び出しはリクエストと呼ばれ、メソッドの実装を実行する行為は実行として知られていた。そのような呼び出しはすべて、常に成功または失敗を示すメッセージで応答し、オプションでそれらをトラップして応答するのは、要求オブジェクトにかかっていた。メソッド呼び出しに、データを渡す方法とそのヒントは、制約として知られており、一般的な「参照別」と「値別」などをカバーしている。

Telescriptは、データの寿命に関して一般的にステートレスだった。インスタンス変数とローカル変数の両方のプログラム内のすべてのデータは、常にシリアル化される。エージェントはいつでも起動または停止でき、状態を失わない。この同じメカニズムにより、エージェントはホスト間で簡単に通信できるようになった。

### 構文とレイアウト
Telescriptの制御とレイアウトはCに触発されたが、その正確な構文はかなり異なっていた。明らかな違いの1つは、定義レベルでCスタイルの中括弧を括弧に置き換え、論理とフロー制御ステートメント内でステートメントをグループ化するための中括弧を保持し、コロンを使用して名前を定義から分離したことだ。次のコードは、Pie型のオブジェクトのインターフェイスを定義する:
   Pie: interface(Object) = (
        public
            name: String;
            initialize: op(name: String);
   );
他の言語で見られる `function` または `sub`に対応するキーワード `op` の使用に注意する。Pieの実装は、Visual Basicに似た方法でモジュールに編成できる1つ以上の `class` オブジェクトで使用できる。.NETの `namespace` 構造。`#include`はヘッダファイルのインポートに使用されますが、インポートはファイル全体ではなく `modules`のローカルである。

Telescriptのエージェントと場所の概念は、エージェントと場所の2つのクラスをサブクラス化するだけで呼び出すというもの。どちらもプロセスのサブクラスであった。コードを明確にするために、これら両方を単一のファイルに配置し、単一のモジュールに集めることもできる。次のコードは、Piesを販売するストアを実装するために必要なエージェントを定義する。
    PieStoreModule: module = (
    	#include "pie.i"
        
    	PieBuyer: class(Agent) = (
    		public
    			live: sponsored op() = {
    					*.go(*.destination);
    					myPie = place@PieSeller.sellPie();
    					*.go(*.originPlace);
    				};
    			);
    			
    	PieSeller: class(Place) = (
    		public
    			sellPie: op() Pie = {
    				aPie: Pie | Nil;
    				aPie = *.getPieFromStock;
    				if (aPie = nil) {
    					PieBuyer(*.distributorTicket, Permit(nil));
    					aPie = *.waitForPie();
    					return aPie;
    				};
    			};
    		);
    );
PieBuyerオブジェクトであるエージェントには、すべてのエージェントが使用する標準の起動メソッドである `live` の単一のメソッドが含まれる。 PieBuyerを作成して呼び出すだけで、ほとんどのOO言語で見られる`new` 操作に似た方法で `live` メソッドが呼び出すが、このメソッドはセットアップ後に呼び出される。 * は、オブジェクト自体、この場合はPieBuyerエージェントを参照して、より一般的に実装されている `self` または `Me`, を置き換える。コードは基本的に、作成時にオブジェクトが作成中に送信された場所に（*.go）を送信する必要がある（*.destination）と述べている。 そこで、一致する場所オブジェクト（この場合はPieSeller）に、SellPieを指示する。このコマンドが完了すると、エージェントは元の場所に戻る。起動したアプリケーションは、myPie変数を調べて、結果を調べることができる。

PlaceであるPieSellerオブジェクトには、sellPieというメソッドが1つある。aPieというローカル変数を定義し、パイ・オブジェクト、またはパイがない場合に使われる "nothing"と定義する。そして、独自のgetPieFromStockメソッド（ここには示されていない）を呼び出してaPieに値を設定しようとし、それが値を返したかどうかをチェックする。うまくいかなかった場合、例えば在庫が空だった場合、新しいPieBuyerオブジェクトを作り、そのリクエストを他の店に送り、応答を待つ。その店はまた別の店にリクエストを転送するかもしれない。この一連の流れが終わり、パイが手に入ったり、手に入らなかったりすると、PieSellerは最後にPieBuyerにパイを返す。
オブジェクトは通常、それを作成した場所によって「所有」される。 所有権はまた、能力やセキュリティ設定も与える。 この言語では、`own {}`構文を使ってオブジェクトの所有権を取得することができる。また、この場合、`sponsored`キーワードを使って、オブジェクトが実行されている場所の所有権の範囲内で実行されることを示すことができる。 これは例えば、エージェントに在庫を見る能力を与えるために使用される。 `sponsoredを`使用すると、コードを`独自の{}`ブロックに置くのとまったく同じ結果になるが、呼び出し側でこれを行うことができる。

Telescript には、`Set`, `List`, `Dictionary`といういくつかの組込みコレクションタイプがあり、最後のコレクションタイプは本質的にテキストインデックスを持つ List である（Dictionary の半分）。Telescriptでよくあるエラーの原因の1つは、コレクション全体はエージェントに渡すことができても、その中の個々のアイテムはその場所に所有されているということであった。そのため、`return MyCollection[someIndex];`を使用すると、ユーザのデバイスにnullとして返されることになる。この解決策は、`DictOwned`と`ColOwned`ヒントを追加することで、返された値の所有者が返されるときに変更され、元の場所に戻るときに結果に連続されるようにすることだった。

上記の PieBuyer クラスは Agent のフレーバーである。Telescript にはミックスインクラスの概念も含まれており、他のクラスに含めることができるコードのみを含むクラスの作成を可能にすることで、多重継承に似た機能を提供する。ミックスインはフレーバーではなかった。

多くの現代的な OO 言語と同様に、Telescriptはインターフェイスと実装を分離し、インターフェイスを`.i`ファイルに、実装を `.t`ファイルに配置した（"t "elescript の t）。珍しいことに、この言語は、複数の`.i`ファイルを結合した3番目のタイプのファイル、`.d`も定義した。コンパイルされたコードは`.s`ファイルに置かれ、`.s`ファイルは `.i`ファイルのリンカ命令によって導かれる。外部アプリケーションフレームワークは、C++ コードを Telescript によって呼び出すことを可能にした。コンパイルされたコードは`.s`ファイルに置かれ、`.i`ファイルのリンカー命令によって導かれる。外部アプリケーションフレームワークは、C++コードをTelescriptによって呼び出すことを可能にした。

## Notes



## 参考書籍

* 『Telescript言語入門』 (アスキーブックス) 単行本 – 1996/7/1 山崎 重一郎 (著), 津田 宏 (著) ISBN 978-4756116567

## 参照
**引用** 

**Bibliography**
 
* 
* 
* 
* 
* 

## 関連項目

* ソフトウェアエージェント