Hatena::Groupcadr

わだばLisperになる このページをアンテナに追加 RSSフィード

2004 | 12 |
2005 | 01 | 02 | 07 | 10 | 11 |
2006 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 11 |

2010-08-15

ELIS復活祭メモ(4) TAO/ELISのメインエディタZENと開発環境

| 23:30 | ELIS復活祭メモ(4) TAO/ELISのメインエディタZENと開発環境 - わだばLisperになる を含むブックマーク はてなブックマーク - ELIS復活祭メモ(4) TAO/ELISのメインエディタZENと開発環境 - わだばLisperになる

現在Common Lispでメジャーだと思われる開発環境は、Emacs上のSLIMEかなと思います。

このSLIMEなのですが、自分の感覚ではLISPマシンの開発環境であるZmacs(Emacs)+LISP処理系の連携に近いものを感じます。

ということで、TAO/ELISの開発環境はどうだったのかということになるのですが、やはりZen(Emacs)+REPLがメインになるようです。

あまり触ってみる時間がなく、詳しく知ることはできなかったのですが、

  1. TAOのリスナー(REPL)上で、edとかzとするとZenが起動する
  2. Zenからファイルを開き、色々書く
  3. 作成した関数を動かしてみるには、C-x uでカーソルの直前の式を評価、C-x yでバッファのファイルを丸ごと評価(ロード?)
  4. C-x C-cでZenを抜けてリスナーへ
  5. 定義した関数を実行してみる
  6. Ctrl-Eでエディタに戻る

を繰り返すようです。また、M-x shell でZen上からシェル(REPL)が開くこともできます(もちろんTAOが開く)

自分は、使用感的には、CADR系のLispマシンの開発環境よりは、MacLISP+Emacsの環境であるLEDITが近いかなと思いました。

キーバインドもC-x yの挙動やC-eでエディタに復帰するところなどはLEDIT由来なのかなと思われました。MacLISP+EMACSのLEDIT環境はどういうものだったかは、PDP-10のエミュレータ環境で試してみたり、萩谷先生の

で伺い知ることができるかと思います。

リスナーについて特筆すべきところは、一番外側の()は省略できることかと思います。

(fib 10)

と打ち込む代わりに

fib 10

と実行できました。

等々、他にもマクロや、マルチプログラミングの定石な開発手順やデバッグ方法なども知りたかったのですが、やはり時間がありませんでした。

試すことを一覧表にでもまとめて持参するべきだったと後悔〜。

2010-08-12

ELIS復活祭メモ(3) TAOではマクロがFUNCALL/APPLYできる

| 21:56 | ELIS復活祭メモ(3) TAOではマクロがFUNCALL/APPLYできる - わだばLisperになる を含むブックマーク はてなブックマーク - ELIS復活祭メモ(3) TAOではマクロがFUNCALL/APPLYできる - わだばLisperになる

TAOマクロがFUNCALL/APPLYできるというのをbitのTAOの連載(no title)を読んで知ったので、やはりこれを試さずにはいられません。

ということで、

(mapcar 'and '(1 2 3 4))
;⇒ (1 2 3 4)

(mapcar 'progn '(1 2 3 4))
;⇒ (1 2 3 4)

(apply 'dotimes '((i 8) (print i)))
;->
0 
1 
2 
3 
4 
5 
6 
7

のようなものを実行して喜んでおりました。

mapcarについては、確認するのを忘れてしまったのですが、複数のリストが取れるので

;; 多分
(mapcar 'and
        '(nil t nil t)
        '(1 2 3 4))
;⇒ (nil 2 nil 4)

のようなことができるのではないかと思います。

TAOでは、mapcarにandを渡したいのにできない!というLISP初心者のFAQも問題にならないわけですね。

mapcarにandを渡していたところ天海さんにandはマイクロ(コード)で実装されているということを教えて頂きました。

andのソースを開く際に、M-.のような感じで、マイクロコードのソースに飛んでいたように思います。

このマイクロコードも色々いじれたりするんでしょうか。次にTAOについて伺える機会があれば伺ってみたいです。

2010-08-11

ELIS復活祭メモ(2) ELIS-8200

| 20:56 | ELIS復活祭メモ(2) ELIS-8200 - わだばLisperになる を含むブックマーク はてなブックマーク - ELIS復活祭メモ(2) ELIS-8200 - わだばLisperになる

市販された、ワークステーション型のELISには、ELIS-8100と、ELIS-8200種類あるのですが、復活祭で詳細を聞くまで基本的に同じLISPの処理系ものだと思っていました。

しかし、説明によると、TAOが載っているのは、8100で、8200は8100やTAOの機能を取り込みつつも処理系は、TAOからCommon Lispに移行していたようです。

(!x 10)のようなTAO独自のものは、SETF等に置き換えられたとのこと。

ELIS-8200は、言わばCommon Lispマシンだったのですね。

TAOから、CLに移行した理由は80年代後半当時の時代の要請(ソフトの互換性等)が主なところだったようです。

処理系がCLということで、質疑応答のときに、ELIS Common Lispの*features*にはどういう風な名前で登録されていたのかを伺いました。

質疑応答の時には何分昔の事ということではっきりしないとのことだったのですが、次の日に8200が起動されたときにわざわざ8200の*features*を表示して見せて頂きました!

確認する限りでは、 ELIS でした。やはり、予想通りというところなのですが、実際に確認できて非常に嬉しかったです。

#+ELISのように書く訳ですね。

しかし、書きながら気付きましたが、8100のTAOを調べるのを忘れていました。なんとなくこれもELISが入っていそうですねー。(Symbolicsのように)

2010-08-10

ELIS復活祭メモ(1) (!(member ...))の謎

| 22:31 | ELIS復活祭メモ(1) (!(member ...))の謎 - わだばLisperになる を含むブックマーク はてなブックマーク - ELIS復活祭メモ(1) (!(member ...))の謎 - わだばLisperになる

もっと時系列に並んだ体系的な記録を書きたいところですが、とりあえず断片的にでも書いてゆきます。

ELISの論文を読んでいたときに、

(!item 2)
(!list (list 1 2 3 4))

(!(member item list) (1+ item))
;⇒(1 3 3 4)

のようになるのが非常に不思議だったので、これを実機で試してきました!

結果として、実際にこういう風になりました。

Common Lispでも、CARを挟んでやれば、

(LET ((ITEM 2)
      (LIST (LIST 1 2 3 4)))
  (SETF (CAR (MEMBER ITEM LIST))
        (1+ ITEM))
  LIST)
;⇒(1 3 3 4)

となります。

TAOでも、

(!(car (member item list)) (1+ item))
;⇒(1 3 3 4)

という風に同じ結果になりました。

CLでこういう動作を追加する場合、defsetfなどで追加できます。

(DEFSETF MEMBER (ITEM LIST) (VAL)
  `(LISPWORKS:WITH-UNIQUE-NAMES (ITEM LIST VAL)
     (SETF (CAR (MEMBER ,ITEM ,LIST))
           ,VAL))))

これで、

(LET ((ITEM 2)
      (LIST (LIST 1 2 3 4)))
  (SETF (MEMBER ITEM LIST)
        (1+ ITEM))
  LIST)

とも書けます。

恐らくですが、TAO/ELISでも、こういった定義があるのではないかなあと想像しています。

2010-08-09

ELIS復活祭参加してきました!

| 23:53 | ELIS復活祭参加してきました! - わだばLisperになる を含むブックマーク はてなブックマーク - ELIS復活祭参加してきました! - わだばLisperになる

8/7〜9でELIS復活祭参加してきました!

運営事務局の皆様、発表者の皆様、素晴しいイベントをありがとうございました!!

割と斜め上な視点ですが、このブログに色々まとめてみたいと思っています。

2010-08-06

(46)TAO/ELIS上でのCプログラミング環境(1986)

| 22:54 | (46)TAO/ELIS上でのCプログラミング環境(1986) - わだばLisperになる を含むブックマーク はてなブックマーク - (46)TAO/ELIS上でのCプログラミング環境(1986) - わだばLisperになる

ELIS復活祭もいよいよ明日!。方向音痴の自分がJAISTまで無事辿り着けるかが心配です!

TAO関係の論文を漁っておりますが、今回は、

です。

前回は、ELISの上にCommon Lispをフルセットで実装したという内容でしたが、今回は、LISPではなくCのプログラミング環境を載せたという内容です。

Lispマシンというと、Lispしか走らないイメージがありますが、Symbolics等でも、Zeta-CというCの処理系や、Ada、Fortran、Pascal、Prolog等の処理系が動いたようです。

本文で説明されている、TAO/ELIS上のCでは、CからTAOに翻訳する方針を採用したそうです。

これにより、LISPのような対話的でインクリメンタルな開発環境が実現できたとのことで、どうしてもTAOに翻訳できないところや、スピードが必要なところでは、マイクロコードで実装したとのこと。

これらのお蔭でCとTAOの関数や変数は等価なものとして扱うことができるそうで、相互に呼び合うことができるとのこと。

また、性能も良好だった様子。色々と凄いですねー。

2010-08-05

(45)TAO/ELIS上でのCommon Lispの実現(1986)

| 22:54 | (45)TAO/ELIS上でのCommon Lispの実現(1986) - わだばLisperになる を含むブックマーク はてなブックマーク - (45)TAO/ELIS上でのCommon Lispの実現(1986) - わだばLisperになる

TAO関係の論文を漁っておりますが、今回は、

です。

気付けば、ELIS復活祭も明後日。2日目の復活イベントでは参加者もELISを触ってみることができるような気配があるのですが、楽しみです!

さて、本文の内容ですが、ELISの上にCommon Lispをフルセットで実装したという内容です。

前回眺めた「Common Lispについて(1985)」の内容を実際に実装してみせたという感じであわせて読むと面白いと思いました。

しかし、批判だけでなく実際に実装してみせるいうのは、凄いパワーですねー。

2010-08-01

(44)Common Lispについて(1985)

| 23:35 | (44)Common Lispについて(1985) - わだばLisperになる を含むブックマーク はてなブックマーク - (44)Common Lispについて(1985) - わだばLisperになる

TAO関係の論文を漁っておりますが、今回は、

です。

題名からするとTAOとはあまり関係のない感じですが、内容はTAO開発者からみたCommon Lispという感じです。

大きく分けると、

  1. レキシカル・スコーピング採用について
  2. setf
  3. Keyword Parameter
  4. Package
  5. Sequence
  6. 多重プログラミング
  7. オブジェクト指向プログラミング
  8. インタプリタとコンパイラ

について言及されています

レキシカル・スコーピング採用について

ダイナミック・スコーピングを減らすという流れには賛成だけれど、レキシカル・スコーピングまでは過剰仕様ではないかという指摘。

TAOでは、Static Scopingというものを採用していましたが、静的範囲を越えるところでは変数の探索モードを変えて外側の変数は、スペシャルでない限りアクセスできないようにしているとのこと。

どういう動作になるのか詳しくは分かりませんが、

(let ((x 8))
  (de bar ()
    x))

(let ((x 8))
  (bar))
;>>> エラー

こういうのはエラーで、

(let ((x 8))
  (declare (special x))
  (de bar ()
    x))

(let ((x 8))
  (declare (special x))
  (bar))
;⇒ 8

これならOKということでしょうか。

レキシカル・スコープの問題としては、レキシカルクロージャーを生成する必要があるのでインタプリタでの動作が遅くなる、ということが挙げられています。

これだと、最近のScheme的なクロージャー万歳なプログラミングスタイルから見ると困るんじゃないかと思ってしまいますが、MIT系のLispマシンや、TAOには、closureという構文があり、

(defun f (x)
  (closure '(x)
    (lambda () (incf x))))

(!foo (f 8))
(funcall f)
;⇒ 9
(funcall f)
;⇒ 10
...

のように明示的に取り込む変数を指定すればクロージャーは作れました。

また、「special変数が閉包に入らないのは実際の使用局面で不便を感ずることが多いのではなかろうか」というのは、closure構文では、スペシャル変数も取り込めるので、

(setf (symbol-function 'print-in-base-16)
      (let ((*print-base* 16.))
        (closure '(*print-base*) 'print)))

(print-in-base-16 10))
;-> A
;=> 10

のような局面を指しているのだと思われます。(これはCommon Lispの仕様では無理です)

setf

TAOには、SETFより汎用的な代入機構があるので、これの解説です。

Keyword Parameter

インタプリタでは動作が遅くなるのと、それまでの慣用述語である、

(memq 'x '(x y z))

(member 'x '(x y z))

などが、

(member 'x '(x y z) :test #'eq)

(member 'x '(x y z) :test #'equal)

に統一されたのが人工的だなあ、とのこと。

Package

Symbolのパッケージへの帰属をpresentとownedに分けているのが複雑ではないかという指摘です

Sequence

オブジェクト指向の枠組みがあるのであればポリモーフィズムに吸収した方がスマートではないか、とのこと。

これは、現在でもCLで良く言われていることですね。(ANSI CLでCLOSが統合された時にも全面的な統一はされませんでした)

多重プログラミング

CLの仕様では何の規定もされていないが、実際に実現するのには、色々問題がありそうだ、という指摘です。

これも、ANSI CLでも規定されなかったので、現在でも問題になっていますね。

オブジェクト指向プログラミング

当時のCLtL1では、オブジェクト指向プログラミングは盛り込まれていませんでしたが、取り込む際の問題点が指摘されています。

インタプリタとコンパイラ

当時、Common Lispはコンパイルして使う言語との認識が広まっていて、当時の実装もインタプリタが極端に遅いことを指摘し、インタプリタとコンパイラの両立を掲げていたのに、実際のところインタプリタは付け足し機能のように使われていて、実質的には両立していないではないかとの指摘。

インタプリタの性能と使い勝手にこだわるTAOの姿勢が伺えます。

最近のCL実装は、SBCLにしろ、CCLにしろコンパイラ指向のものが多いのですが、デバッグ時のステップ実行等の使い勝手はあまり良くありません。

インタプリタだとどういう使い勝手だったのか自分も知りたいところです。

まとめ

とはいえ、CLを否定しているわけではなく良いところはTAOに取り込む方向で進んでいて、合せられるところは、極力CLに合せるとのことで、当時のLispマシンの処理系がそうであったように、CLのスーパーセットとしても機能するように考えていたように思われました。

2010-07-31

(43)Object - Oriented Programming in Lisp(1983)

| 21:03 | (43)Object - Oriented Programming in Lisp(1983) - わだばLisperになる を含むブックマーク はてなブックマーク - (43)Object - Oriented Programming in Lisp(1983) - わだばLisperになる

TAO関係の論文を漁っておりますが、今回は、

です。

論文にTAOの名前がないので見落して抜かしてしまっていましたが、TAOのオブジェクト指向プログラミング方面について書かれています。

TAOでは、レシーバとメッセージの書き方から

[3 + 3]

のように中置で書けるというお馴染の解説から具体的な実装戦略などが詳細に解説されています。

これまで読んだところでは、TAOのオブジェクト指向プログラミングについては、これが一番詳しい気がします。

また、後半はZetalisp等のFlavorsや、Interlisp-DのLoops等との比較もあります。

文中でも少しだけ言及されていますが

(3 + 3)

と書けるだけでなく、TAO

f(x)
;; (f x)と同じ

のようにも書けるようです。

この辺りについては、

no title

に詳しく解説があります。

2010-07-30

(42)TAOにおける代入計算機構(1985)

| 23:47 | (42)TAOにおける代入計算機構(1985) - わだばLisperになる を含むブックマーク はてなブックマーク - (42)TAOにおける代入計算機構(1985) - わだばLisperになる

TAO関係の論文を漁っておりますが、今回は、

です。

8/7〜9日のELIS復活祭まで一通りの論文を読み終えておこうと思っていたのですが、まったりしているうちにあと1週間位しかなくなってしまいました。

あと、十本位あるのですが…。

とりあえず、90年代以降は、TAO/ELISではなく後継のTAO/SILENTになるようなのでTAO/ELIS時代は眺めておきたいところ。

本文は、TAOのコードの見た目の特徴にもなっている、代入機構(!や!!)についてです。

ちなみに!や!!より前には、:や、::で表現されていたようで、!に切り替わったのは、この論文の後位のようです。

この代入の機構は、CLでいえば、(setf (car foo) :foo)のようなところを、TAOだと(:(car foo) :foo)と書けます。

CLの場合は、マクロで実現していますが、TAOでは、これをマイクロプログラミングレベルで実現しているとのこと。

読み出してきた値の保持には専用のレジスタが使われます。

TAOだとsetqもマクロで(:x 'foo)の方がよりプリミティブになるとのこと。

(:x 123)

というのは元より

(defvar y (list 1 2 3 4))
(defvar n 2)

(:(member n y) (+ n 1))
;⇒ (1 3 3 4)

(defvar flip nil)
(defvar flop 42)
(defvar x (cons 1 2))

(:(cond ((null x) (car x))
        (t (cdr x)))
  flop)
;⇒ (1 42)

のようなこともできるようです。

また、(:x y)という式は、(:という記号になり、代入のタグが立ったリストになるそうで、carもcdrも取れるとのこと(どういうことになるのやら)

もう一つ特徴的なのが、自己代入式ですが、

(::cons :x y)

のように書き、CLだと

(seq x (cons x y))

のような動作になります。

この場合でもTAOの場合、xの参照は、代入レジスタのお蔭により1回で済むということです。

また、最後の方は、locativeというMITのLISPマシンでもお馴染のデータ型との組み合わせの解説があります。

locativeだとアドレスを直接扱うことができるのですが、これと件の代入機構と、Smalltalk的なメッセージセンドの構文が融合することによりかなりカオスなことになっていますので、興味のある方にはかなり面白い内容ではないかなと思います。

2010-07-25

(41)NUE/TAO/ELISのOS的側面(1984)

| 19:50 | (41)NUE/TAO/ELISのOS的側面(1984) - わだばLisperになる を含むブックマーク はてなブックマーク - (41)NUE/TAO/ELISのOS的側面(1984) - わだばLisperになる

TAO関係の論文を漁っておりますが、今回は、

です。

タイトルは日本語ですが、内容は英文です。

軽くNUEについて説明したあと、マルチプログラミング、OBLISTグラフ(多重の名前空間について)、マルチユーザー対応と説明が続きます。

英文だけに海外のLispマシンとの違いをメインに説明されているように思えました(Zetalispとの比較など)

海外のLispマシンがビットマップディスプレイの個人占有マシンを指向していたのに対し、TAO/ELISのマルチユーザーで、9600bpsのターミナルという立ち位置は面白いなと思いました(高価なビットマップディスプレイは後々に普及してから検討する方針だったようです)

2010-07-22

(40)LispマシンELISのアーキテクチャ-メモリレジスタの汎用化とその効果-(1983)

| 22:25 | (40)LispマシンELISのアーキテクチャ-メモリレジスタの汎用化とその効果-(1983) - わだばLisperになる を含むブックマーク はてなブックマーク - (40)LispマシンELISのアーキテクチャ-メモリレジスタの汎用化とその効果-(1983) - わだばLisperになる

TAO関係の論文を漁っておりますが、今回は、

です。

前回眺めた「LispマシンELIS上の新Lisp TAO(1982)」ではTAOが新しくなり3つのパラダイムを扱うようになっていましたが、マシンの側も応じるように変化しています。

マシンの設計においては 命令セット ありきで設計が始まるそうなのですが、ELIS の場合は、LISP処理系でのインタプリタとコンパイルコードの完全両立と、インタプリタの高速化をねらうという所から出発したそうで、

  1. 特定の Lisp に依存しない, リスト処理に共通な機能の充実.
  2. キャッシュメモリなしでもセルアクセスが処理のネックにならないこと.
  3. 集積化の際にも, 実装しやすい構造をもつこと. 集積回路の設計には同一の構造物を繰り返し用いることが望ましい

ということが具体的なアーキテクチャを決定する要因となったそうです。

これらの発想から生まれたのが、「Lisp マシン ELIS の基本設計(1980)」でもちょっと出てきたメモリ多目的レジスタ (MGR) とのこと。

メモリ多目的レジスタの活用例について詳細が述べられています。

ハードウェア関係が分からないので内容は自分には難しいですが、LISPとハードウェアが密に連携していたということはなんとなく分かります。

2010-07-19

(39)LispマシンELIS上の新Lisp TAO(1982)

| 04:18 | (39)LispマシンELIS上の新Lisp TAO(1982) - わだばLisperになる を含むブックマーク はてなブックマーク - (39)LispマシンELIS上の新Lisp TAO(1982) - わだばLisperになる

TAO関係の論文を漁っておりますが、今回は、

です。

これまで眺めた論文では、LISP+Prologという感じでしたが、本文あたりからSmalltalkが加わるようです。

内容は、Prologとの融合、Smalltalkとの融合という流れて進みます。

Prologとの融合

まずは、Prologとの融合で、ユニフィケーションの関数化について説明があり、無名関数のLAMBDAのようにユニフィケーションが書けるようです。

((lambda (x) (car x)) '(1 2 3 4))

に対して

((&+ (*x . *y) *x) (1 2 3 4))
; ⇒ 1

これは主にパターンマッチの機能で比較的分かりやすいかと思います。

次にバックトラックなどですが、

(Hclauses (&+ ...) ... (&+ ...))

という形式で、本体内の式でnon-NILな式があればその値を返し、そうでなければバックトラックする述語の無名関数版のようなHclausesが基本になるようです

((Hclauses (&+ (*x *y . *z) *x) (&+ (*x *y *x) *y)) (1 (*a 2) *a))

は、Prologでいう

hclauses([X,Y|Z], X).
hclauses([X,Y,X], Y).

?- hclauses([1,[A,2],A],X).
X = 1 ; (バックトラックさせる)
A = 1,
X = [1, 2].

のようなものの無名版のようです。

他には&や、!があり、prologのように、","で継げて書くには、&を利用するようです。

(& (*x *y)    
   (belong *x (1 2))  
   (print (list 'pre *x (if-undef *y 'U)))
   (belong *y (4 2))                      
   (print (list 'post *x *y))             
   (== *x *y) )

は、

?- belong(X,[1,2]),
    print([pre, X]),nl,
    belong(Y,[4,2]),
    print([post,Y]),nl,
    X=Y.
[pre, 1]
[post, 4]
[post, 2]
[pre, 2]
[post, 4]
[post, 2]
X = 2,
Y = 2 ;
false.
% belongの定義
belong(X,[X|_]).
belong(X,[A|Y]) :- belong(X,Y).

的な感じなのでしょうか。

また、Prologと違う点は、論理変数にはスコープを設定でき(上のコードの例でいうと&の次のリストで利用する変数を宣言している)、このスコープによって色々と挙動を変化させることができるとのことで、挙動の違いの解説があります。

Smalltalkとの融合

ぱっと見た感じでは、MITのFlavorsのような感じですが、角括弧の記法で、

[<receiver> <message> . <args> ]

と書けるようです。

[3 + 4]
;⇒ 7

と表現できるようなのですが、丸括弧も使えるようなので

(3 + 4)
;⇒ 7

(defun factorial (n)
  (cond (n = 0) 1)
        (t (n * (factorial (n - 1)))) )

のように部分的に中置だったり前置だったりカオスな記述もできたようです。

パフォーマンスについては、「TAO では Lisp で定義した append と Prolog 風に定義した append の速度比は 1:1.5 以内, Lisp 式 (+ x y) と Smalltalk 風の (x + y) とは同速度となっている.」とのことで3つのパラダイムは十分に混合して利用できたようです。

2010-07-18

(38)New Unified Environment(NUE)の基本構想(1982)

| 01:03 | (38)New Unified Environment(NUE)の基本構想(1982) - わだばLisperになる を含むブックマーク はてなブックマーク - (38)New Unified Environment(NUE)の基本構想(1982) - わだばLisperになる

TAO関係の論文を漁っておりますが、今回は、

です。

これまで眺めてきたELISのプロトタイプはTAO/60で記述されていて、TAO/60は既存のLISPの拡張という感じなのですが、1982年のNUE(New Unified Environment)辺りからLisp+Prolog+Smalltalkという感じになってきます。

本文では、まだSmalltalkの取り込みの話はでてきておらず、Prologとの融合について解説されています。

まず、複数のパラダイムを統合する核言語としてLISPを採用した理由が述べられていますが「むしろ Lisp というより, S式という「前言語的言語」を基本枠組として選んだと言えよう」とのことで、S式の柔軟性が理由のようです。

また、S式については、「S式についてもう1つ注意しておかなければならないのは, 人間と機械の間の「共通言語 (深層言語)」としてのS式の優位性, 自然さである. S式は入出力が常に整形されていれば人間にとって決して扱いにくいものではない. もちろん機械にとってS式は機械内部表現と1対1に対応している. 我々はS式が, 人間と機械の双方向通信にとって, 少なくとも現時点の我々の技術レベルにおいて, 最も自然で直接的であると考える. 」とも述べられていてS式LOVEな人にとっては頷けるところも多いかと思います。

また後半は、PrologとLISPの融合について述べられていますが、当時の同様の試みであるLOGLISP、PROLOG/KR、DURAL等との比較が述べられています。

ちょっとした発見としては、論理変数は、TAO/ELISでは、

(equall _x _u)

のように_を付けて書きますが、この本文の時点では、Prolog/KRのように

(equall *x *u)

と書いていたようで、色々と模索が伺えます

2010-07-16

(37)A Principle of New Programming Environment(1981)

| 21:16 | (37)A Principle of New Programming Environment(1981) - わだばLisperになる を含むブックマーク はてなブックマーク - (37)A Principle of New Programming Environment(1981) - わだばLisperになる

TAO関係の論文を漁っておりますが、今回は、

です。

本文は、NUE (New Unified Environment)という、(1) Lisp machine (ELIS) 上で, (2) 主として玄人の programmer が, (3) display 端末を介して, 高度に対話的に, (5) かなり大規模な programming を行なうためのプログラミング環境の構想について述べられています。

LISPの処理系側の大規模なプログラミングをするための工夫としては、OblistをノードとしたOblist graphというものを考え、これにより同一のシンボル名を扱うことを可能にしているとのこと。

また、対話環境については、Emacsのようなモードレスなエディタを想定していて、コマンドの履歴や処理のバックグラウンド化や切り替えにも対応するということで、当時のMITやXeroxのLispマシン相当の機能は想定されていたようです。(当時のMITのLispマシンの開発環境は今でいうSLIMEのような機能を既に実現していました)

また、他のLispマシンがAltoのようなシングルユーザー向けの環境であるのに対してTAOはTSS的にマルチユーザーであることを指向していたようなのですが、ここでも「2人以上の人間が同一の Lisp 環境で共同作業を行なえる. また1人の人間が複数の window を通じて, 同一のみならず別の Lisp 環境と対話できる.」ことを掲げています。

それにしても、マルチユーザーのLISP環境というのは面白そうですね。