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-07-10

(33)TAO/ELISのUNIXへの移植(1995)

| 23:32 | (33)TAO/ELISのUNIXへの移植(1995) - わだばLisperになる を含むブックマーク はてなブックマーク - (33)TAO/ELISのUNIXへの移植(1995) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っております。

来月8月7〜9はJAISTでELIS復活祭ということで私も3日間参加することにしました。

もちろん月曜は会社を休みますw

東京からだとJAISTって結構遠いみたいですが、一緒に電車でJAISTに行って頂ける方を募集しています。

ということで、折角のELIS復活祭に向けてCiNiiの論文漁りもTAO/ELIS関係を中心に眺めていこうかなと思います。

ということで、今回は、

です。

本文は、ELISというLISPマシンのマイクロコードをまるごとCに変換してFreeBSD上でTAO/ELISを稼動させたという内容です。

1995年のPentium II 300MHzのマシンで実機の2.5倍のスピードで稼動したとのこと。

また、TAO/ELISはLISPマシンにしては他に類をみないマルチユーザー環境ですが、移植環境でも8人までログインして同時につかえるとのこと。

また、本文の6年後に続編ような「マイクロプログラムの静的変換による記号処理システムの移植とその性能評価」が書かれているのですが、nue.orgでもHTML版が読めるので、改めてHTMLを眺めてみたところ、なんと内容がアップデートされていました!

FreeBSD 8.0や、MacOSXに移植しオリジナルの70倍のスピードで動くとのこと。

TAOプログラムもすべて動くようになっているとのことです。凄いですね!

2010-07-04

(32)Concurrent Common LISP(1988)

| 20:20 | (32)Concurrent Common LISP(1988) - わだばLisperになる を含むブックマーク はてなブックマーク - (32)Concurrent Common LISP(1988) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

Concurrent Common LISPは、Concurrent LISPというLISP1.5をベースに並列処理機能を付加した処理系のベースをCommon Lispにしたもののようです。

Concurrent LISPでは、プロセスは、それ単体でフォームを評価することができる実体として定義されているそうで特徴としては、

  1. 動的に起動され親子関係がある
  2. プロセスのIDもしくは、プロセスの親子関係でプロセスを特定できる
  3. プロセス間のコミュニケーションのため変数の共有とメッセージの送信機能がある

等があるそうです。

Common Lispには並列の機能はありませんが、並列機能の拡張として

  • starteval
  • cr
  • ccr

という3つのスペシャルフォームを用意しているようです。

また、プロセス間の変数の共有は、親プロセスの大域変数で行なうとのこと。

ちなみに、Concurrent Common LISPが稼動していたマシンはどうやらSonyのNEWSだった模様。

2010-07-02

(31)第二回 Lisp コンテスト(1979)

| 23:20 | (31)第二回 Lisp コンテスト(1979) - わだばLisperになる を含むブックマーク はてなブックマーク - (31)第二回 Lisp コンテスト(1979) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

日本でLispが流行しはじめた(情報処理学会で注目され始めた)のは、1974年7月の記号処理シンポジウムがきっかけだったとのことで、この時に初めて日本中のLispに興味のある人々が一堂に会したそうです。

第一回 Lisp コンテストが開催され、日本のLispの状況があきらかになったとのこと。

第二回 Lisp コンテストは、第一回の内容を継承しつつ海外からの参加も呼び掛けてみていたようです。

コンテストの内容ですが、基本的には、ベンチマークで処理系の速度を測るというもので、本文に詳しくベンチの解説があります。

また、当時の処理系はかなり多様で参加者はそれぞれ別の方言という感じですが、共通で動かせるようなものがお題になっています。

ちょっと調べたところでは、第三回まで開催されていた様子で、三回目は、1985年に、第一回 Prologコンテストと共に実施されたようです。

そのうち第四回が開催されることを期待したいですね。

2010-06-24

(30)日米並列Lispワークショップに参加して(1989)

| 21:36 | (30)日米並列Lispワークショップに参加して(1989) - わだばLisperになる を含むブックマーク はてなブックマーク - (30)日米並列Lispワークショップに参加して(1989) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

本文は、今から21年前の1989年に東北大学で開催された日米並列Lispワークショップのレポートです。

最近では、プロセッサの速度向上が頭打ちになりつつあり、GPGPU等を利用した並列コンピューティングが熱くなりつつありますが、LISP界では、大体、25年前から15年前あたりまで並列計算が熱かったようです。

代表的なところでは、超並列プロセッサのConnection Machineで稼動する *Lispや、Connection Machine Lisp(完成しなかった様子)がありますが、このレポートを読むと、*Lisp以外にも様々な処理系があったことが分かります。

このワークショップで発表された処理系だけでも、

  1. Multilisp(Schemeの拡張)
  2. Mul-T(Tの拡張)
    • メモリ共有型ハードウェアで稼動。future機能
  3. QLisp
    • メモリ共有型ハードウェア
  4. TOP-1 Common Lisp
    • KCLを拡張したもの。future。明示的プロセス生成あり。
  5. PaiLisp
    • Schemeを並列拡張
  6. Concurrent Scheme
  7. mUtiLisp
  8. MultiScheme
  9. TAO
  10. ABCL/R
    • 並列自己反映オブジェクト指向LISP
  11. ABCL/1
  12. PMLisp
  13. Lispマシン EVLIS

などなどかなり多様です。

並列コンピューティングが身近になりつつある今、また並列LISPが身近になることがあるやもしれません!

2010-06-22

(29)AIP-LISP : (1)レジスタ・アロケータ(1989)

| 12:46 | (29)AIP-LISP : (1)レジスタ・アロケータ(1989) - わだばLisperになる を含むブックマーク はてなブックマーク - (29)AIP-LISP : (1)レジスタ・アロケータ(1989) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

AIP-LISPとは、東芝が作成していたCommon Lisp処理系で(時代からしてCLtL1)、

AS3000というSun-3を日本語機能を強化したワークステーションにAI処理専用のプロセッサを付けた構成で稼動していた処理系だったようです。

そしてAIPとは、AIプロセッサの略のようで、RISC風なタグアーキテクチャだったようです。

本文では、そのAIPでの変数のレジスタ割付けについて書かれています。

どうも80年代後半はCommon Lisp処理系の実装が熱い時代だったようです。

2010-06-20

(28)電子メール討論 : Common Lisp における実例(1987)

| 19:57 | (28)電子メール討論 : Common Lisp における実例(1987) - わだばLisperになる を含むブックマーク はてなブックマーク - (28)電子メール討論 : Common Lisp における実例(1987) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

Common Lisp言語の仕様は1981年ごろからメーリングリストを利用して行なわれていたようです。

今でこそ電子メールは当たり前になっていますが、1981年といえば時代を相当先取りしていたのではないかと思います。

討論の方法は、特に進行役は立てず、流れるままに行ない、必要があれば調停役が調整、という感じだったとのこと。

時代が時代だけに転送量が問題だったらしく仕様変更の提案に議論が白熱してメールサーバーがパンクすることもあったようです。

2010-06-17

(27)マルチパラダイム言語処理系MCによるプログラム開発(1990)

| 21:00 | (27)マルチパラダイム言語処理系MCによるプログラム開発(1990) - わだばLisperになる を含むブックマーク はてなブックマーク - (27)マルチパラダイム言語処理系MCによるプログラム開発(1990) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

このMCという処理系は、Meta Computing environmentの略だそうで、LISPとPrologを融合した処理系だそうです。

LISPとPrologの融合というと有名なところではTAOがありますが、MCの融合の方針は、手続き的な記述の方が楽に書けるところは、LISPスタイルで記述、宣言的な記述だと上手く書ける場合は、Prologスタイルで書く、というように書き分けつつ共存する、というもののようです。

具体的にどういう風に共存しているかですが、Prolog側は、Uranus(Prolog/KR)のようにS式で記述。

関数の定義は、CLと同じく、DEFUN、Prologの述語の定義は、DEFPREDICATEという風にし、LISPからProlog側を呼ぶには、(?-)、(?ALL)等の?から始まるフォームを利用し、逆にPrologからLISPを呼ぶには、(IS)や、(ARE)を使うとのこと。

また、開発事例として、MC/LISPコンパイラを挙げいて、コンパイラの場合、パターンマッチを活用できるためPrologを主体とし、Prologで処理しにくいところはLISPで記述、という風にお互いを補いつつ効率的に記述できたとのことです。

LISPとPrologが融合した処理系がTAOの他にあったとは意外でした。

2010-06-15

(26)最近のLisp言語(1993)

| 20:11 | (26)最近のLisp言語(1993) - わだばLisperになる を含むブックマーク はてなブックマーク - (26)最近のLisp言語(1993) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

最近といっても1993年なので17年前のことになります。

最初にLISPの歴史的なところをざっと紹介して、

LISPの基本的なところを解説。

最近のLISPとして、Common LispとSchemeを紹介しています。

新しいところとして、

  1. タイプ
  2. レキシカル・スコープ
  3. クロージャ
  4. 構造体
  5. パッケージ
  6. オブジェクト指向
  7. ウィンドウ・インターフェイス
  8. 並列機能

を取り上げていて、最後にSchemeの紹介があります。

CLX〜Schemeと他の伝統的なLISP方言との比較等、内容は盛り沢山で、今読んでも面白いと思います。

2010-06-12

(25)動的オブジェクト指向言語Dylan(1995)

| 16:03 | (25)動的オブジェクト指向言語Dylan(1995) - わだばLisperになる を含むブックマーク はてなブックマーク - (25)動的オブジェクト指向言語Dylan(1995) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

CiNiiにDylan関係のものもあったりしないかなと探してみたら、ありました!

Dylanは、Algol文法を持つLISP系言語として知られていると思いますが、当時、Appleが中心となって開発されていた言語です。

使ってみると、LISP的なところを取り入れた言語というよりも、LISPの見た目をAlgol風にして機能を足したというところで、中身がずばりLISPなのでLISPの人が好むのも分かる気がします。(そもそも初期はS式でも書けました)

Dylanが提案された当時のターゲットとしては、C++や、Cを利用している層で、C++を置き換えることを狙っていたようです。

Common Lisp等と違うところとしては、開発環境と、実行環境が分かれているということが挙げられていて、これは、単体の実行ファイルを配布することが念頭にあった為の様子。

CL(CLOS)の美味しいところをベースに、Rubyの見た目で、単体の実行ファイルを配布できる、という今でも美味しそうな言語ですが、ぱっとしなかったのが残念です(LISPの人には)

今でもopendylan.org等で開発が続けられているので興味のある方は如何でしょうか。

Appleで主力開発言語となっていたならば、iPadでもDylanが動いていたことでしょう…。

2010-06-09

(24)KCl(Kyoto Common Lisp)(1984)

| 14:20 | (24)KCl(Kyoto Common Lisp)(1984) - わだばLisperになる を含むブックマーク はてなブックマーク - (24)KCl(Kyoto Common Lisp)(1984) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

KClは国産のCommon Lisp処理系としても、初期からあるCL実装としても世界的に有名かと思います。

今では、KClそのものを使うことはあまり多くないかと思うのですが、ECLや、GCLはKClの系統です。

本文は、そのKClの開発動機と開発について、当時のCL界について等が語られています。

1983年の春に研究所に新しく導入される予定のミニコンでLISP処理系が動いていなかったのと、ちょうどCLtL(Laser版)がほぼ完成しているのを知って、それじゃあ、作ってみようということになったのがKClの初まりだったようですが、本文は、1984の春に書かれていて、CLtLの最新版も完成前のMary Poppins版ということで、KClは、CLtL1より前から存在していたんですね。

当時の状況としては、Spice Lispや、Lispマシンのように既存のLISP処理系が、CL準拠に対応するというのが多かったようなので、Cで一から書かれたというのも異色だったようです。

また、実装についても色々述べられていますが、KClでもインタプリタの速度を重要視していたようです。

等々、他にも色々面白いことが書かれています。

2010-06-07

(23)新ELISのプログラム開発支援系(1992)

| 19:54 | (23)新ELISのプログラム開発支援系(1992) - わだばLisperになる を含むブックマーク はてなブックマーク - (23)新ELISのプログラム開発支援系(1992) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

本文では、国産LispマシンのELIS上で稼動していた、ELIS Common Lispの開発支援について述べられています。

  1. インタプリタ環境の重視
  2. 特定のプログラミングパラダイムに依存しない開発支援機能

が柱となる方針で、インタプリタ環境の重視というのは、TAOから受け継がれたもののようですし、プログラミングパラダイムに依存しないというのもProlog + Smalltalk + TAOのかわりにCommon Lispということで、これも受け継いだ特性のようです。

具体的な、支援としては、

  1. 3つの異なったパラダイムでも上手く動く実行追跡機能
  2. データ構造の簡単な表示/変更機能
  3. 3つの異なったパラダイムでも上手く動くデバッガ

実行の追跡については、Common Lispフック機能(ANSI CLではなくなってしまいました)を拡張する形で実装していて、論理型も同じくフックが用意されています。

そういえば、ANSI Common Lispからはなんでevalhook/applyhookが消えてしまったんでしょう。

HyperSpecに書いてあったりするかもしれないので探してみたいところです。

2010-06-03

(22)LISP 構造エディタ(<特集>エディタ)(1984)

| 07:17 | (22)LISP 構造エディタ(エディタ)(1984) - わだばLisperになる を含むブックマーク はてなブックマーク - (22)LISP 構造エディタ(エディタ)(1984) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

近頃のエディタといえば、LISPの編集でも普通のテキストエディタ+S式編集支援機能という感じですが、80年代位には、構造化エディタというS式単位で編集するエディタもあったようです。

Interlisp等が代表格らしいのですが、本文では、EMACSはちらっと紹介するに留まり、Interlispのエディタを中心に紹介しています。

大体の動作も想像できるほど、かなり詳細に紹介されていますので、構造エディタを詳しく知りたい人には良い資料かなと思いました。

2010-05-31

(21)高速Common Lisp - HiLISPの実現(1986)

| 06:51 | (21)高速Common Lisp - HiLISPの実現(1986) - わだばLisperになる を含むブックマーク はてなブックマーク - (21)高速Common Lisp - HiLISPの実現(1986) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

HiLISPは、日立のメインフレームHitac Mシリーズ上で動いていたCL処理系です。

日立もCLの処理系を作っていたなんて意外ですが、80年代後半には色々なところがCL処理系を作成していたようで、本文は、その実装方法を紹介しています。

HiLISPは、コンパイルされた関数の高速実行を目指しつつ、インタプリタの性能も犠牲にしない、という方針だったようです。

最近は割と、SBCLや、Clozure CLのようなコンパイラ指向の処理系が目立つのでインタプリタの速度を気にしているという話はあまり聞かない気がするのですが、当時はインタプリタの速度も重要視して実装しているところが割と多い気がしています。

実装の技法として、

  1. 多値の処理方法
  2. インタプリタでの変数管理で用いるディープバインディングの高速化
  3. 無限エクステントと、間接ポインタの併用

が挙げられています。

2010-05-28

(20)TAOのパッケージシステム(1994)

| 07:59 | (20)TAOのパッケージシステム(1994) - わだばLisperになる を含むブックマーク はてなブックマーク - (20)TAOのパッケージシステム(1994) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

本文のTAOは、ELIS上で稼動する、TAO/ELISではなくて、記号処理専用マシンのSILENT上で稼動するTAO/SILENTとのこと。

TAOはCommon Lispとは違ったパッケージシステムを採用していて

Common Lispとちがっているところで特徴的なところは、

  1. OSレベルでのシンボルとパッケージの保護
  2. package pathがあり、UNIXシェルのPATHのように複数pathを登録できて、先の方が優先される
  3. 外部シンボル、内部シンボルの違いはなく、":"で区切られるのみ("::"はない)
  4. システムやアプリが提供するシンボルはユーザーには変更不可なのでエイリアス機構を提供

TAO/ELISや、Lisp machine lispでは、パッケージが階層構造を取れたようなのですが、本文では、階層化に触れられていませんでした。TAO/SILENTはCLと同じように階層化されてなかったりするのでしょうか。

全然関係ないですが、本文中の「TAOは、SILENTの機械語」というのにグッと来ました

2010-05-27

(19)ELIS Common Lispのマルチプログラミング機能(1989)

| 13:24 | (19)ELIS Common Lispのマルチプログラミング機能(1989) - わだばLisperになる を含むブックマーク はてなブックマーク - (19)ELIS Common Lispのマルチプログラミング機能(1989) - わだばLisperになる

まったりとCiNiiのLISP関係の論文を漁っておりますが、今回は、

です。

国産のLISPマシンであるELISでは、TAOが動いていたというのは知られるところだと思うのですが、CLも動いていたというは、CiNiiで論文が読めるようになってから知りました。

ELIS Common Lispは、TAOの機構を継承し、CLと競合するところは、CLを優先、ということなので、TAOのCL版という感じだったのかもしれません。

本文は、ELIS CLのマルチプログラミング機能について述べられていますが、CLでは、マルチプログラミング機能は仕様に定められておらず(当時のCLtL1でも今のANSI CLでも)、拡張部分となります。

特徴としては、単一アドレス空間で、リエントラント性が確保されるような拡張がされていて、

  1. 名前空間は、プロセスごとにCLのパッケージを切る
  2. 同期プリミティブは、言語仕様には含めず、システムが提供するものを利用する
  3. トップレベルの変数もプロセスごとにLETでの束縛のように振る舞う(大域の共有はしない)。
    1. 共有する場合は、defglobalか、defconstant宣言する。defglobalで宣言すると束縛はできず、代入しかできない変数となる
  4. シンボルの属性リストはプロセスごとに異なるようにする。共通にしたい場合は、特別な宣言をする

等が実現方法として述べられています。

ここ1年位で、SBCLにも拡張としてdefglobalが導入されて、その性質も同じく代入しかできないというものですが、他のCL処理系の拡張や、MIT系のLispマシンにもあるようなので、この辺りは定番なのかもしれません。

プロセスごとにごとにパッケージを用意するというのは、自動で行なわれるのか、ユーザーがそういうコーディングをするものなのか詳しく述べられてはいませんが、興味深いです。

ちなみに、SBCLのスレッドでは、

  1. 大域のスペシャル変数は、全スレッドで共有される
  2. (ローカル)束縛のスペシャル変数は、親子スレッドで共有されない
  3. (ローカル)レキシカル変数は、親子スレッドで共有される

となっているようです。最近のCL処理系は大体こういう動きみたいですが、振舞い的にはELIS CLと結構違いますね。