What's lambda
TOKAJI, Akio
Lisp で使われる lambda というシンボルの由来についての記述です。
●『[対話による] Common Lisp 入門』(p.137)、栗原正仁 著、森北出版
| lambda の由来は？
|
| 関数をあらわすラムダ式に出てくるシンボルlambdaとはいったい
| 何だろう？
| ラッセルとホワイトヘッドという数学者の書いた Principia
| Mathematica という有名な本では、関数をあらわすのにパラメー
| タにカレット記号＾を付けて
|
| へ
| ｘ(ｘ+ｘ)
|
| のように表していた。しかし、チャーチという数学者は、パラメー
| タの上にカレットを付けるのはタイピングがわずらわしいので、
| カレットを前にもってきて
|
| ＾ｘ(ｘ+ｘ)
|
| とした。しかし、これではカレットの下に何も文字がないので奇
| 妙だ。そこでチャーチはカレットのかわりに見かけが似たΛ（ギ
| リシャ文字のラムダの文字）を使って Λｘ(ｘ+ｘ) になおした。
| しかし、Λは論理学に出てくる連言(and)と似ているので混乱し
| やすい。結局、チャーチはラムダの小文字を使ってλｘ(ｘ+ｘ)
| とすることに落ち着いた。
|
| その後、この分野はラムダ計算と呼ばれるようになり、チャーチ
| はこの分野で偉大な業績をあげた。1960年ころ、チャーチが指導
| した学生マッカーシーがラムダ計算をヒントにして Lisp を考案
| した。
| コンピュータのキーボードにはλの文字がないので、マッカーシー
| はかわりに lambda を用いて(lambda (x) (+ x x)) と表したの
| だった。
|
| 参考文献
| P.Norvig: Paradigms of Artificial Intelligence Programming:
| Case Studies in Common Lisp, Morgan Kaufman, 1922.
--
TOKAJI, Akio
mailto:tok...@ppn.ne.jp
http://www.ppn.ne.jp/‾tokajia/
TOKAJI, Akio
Lisp は、現状では、実践的なプログラミングで使われることは少ないかもしれ
ませんが、Emacs のマクロ言語などとして採用されたことにより、意外にポピュ
ラーになりつつあります。
|Lisp が作られたのは、FORTRANとほぼ同時期の1960年です。Lispは作成当初か
ら
|人工知能を中心とする記号処理を応用分野とし、数学的性格を骨格としていま
し
|た。(『LISP入門』､黒川利明著､培風館)
|そもそもLispは今を去ること20年以上前に、当時MIT（マサチューセッツ工科大
学）
|にいたジョン・マッカーシーなる人物が発明したプログラミング言語でありま
す。
|今日残っているプログラミング言語の中ではFortranと並ぶ古い歴史を誇ってい
る
|のであります。Lispという名前は、アー、当然イングリッシュなのであります
が、
|List Processing Language の頭の Lis と P を抜き取ってできたものでありま
す。
|(『初めての人のためのLISP』､竹内郁雄著､サイエンス社)
TOKAJI, Akio wrote:
>
> Lisp で使われる lambda というシンボルの由来についての記述です。
>
> ●『[対話による] Common Lisp 入門』(p.137)、栗原正仁 著、森北出版
> | lambda の由来は？
> |
> | 関数をあらわすラムダ式に出てくるシンボルlambdaとはいったい
> | 何だろう？
> | ラッセルとホワイトヘッドという数学者の書いた Principia
> | Mathematica という有名な本では、関数をあらわすのにパラメー
> | タにカレット記号＾を付けて
> |
> | へ
> | ｘ(ｘ+ｘ)
> |
> | のように表していた。しかし、チャーチという数学者は、パラメー
> | タの上にカレットを付けるのはタイピングがわずらわしいので、
> | カレットを前にもってきて
> |
> | ＾ｘ(ｘ+ｘ)
> |
> | とした。しかし、これではカレットの下に何も文字がないので奇
> | 妙だ。そこでチャーチはカレットのかわりに見かけが似たΛ（ギ
> | リシャ文字のラムダの大文字）を使って Λｘ(ｘ+ｘ) になおした。
> | しかし、Λは論理学に出てくる連言(and)と似ているので混乱し
> | やすい。結局、チャーチはラムダの小文字を使ってλｘ(ｘ+ｘ)
> | とすることﾉ落ち着いた。
Hironobu Suzuki
>>>>> "TO" == TOKAJI, Akio <tok...@ppn.ne.jp> writes:
In article <34483F...@ppn.ne.jp> "TOKAJI, Akio" <tok...@ppn.ne.jp> writes:
TO> Lisp は、現状では、実践的なプログラミングで使われることは少ないか
TO> もしれませんが、
あまり知られていないけれども、ニンテンド６４のスーパーマリオ６４で使っ
ている空間処理ツールN-WORLDはCommon Lispを使って開発しているし、プレス
テのクラッシュランデグーは、Common Lisp上に構築されたGOOL (Game Object
Oriented Language)で作られています。
MITではHTTPサーバをCommon Lispで書いています。これが、Common Lispで書
いるだけあって、色々と拡張性に優れていそうで、いいなぁ、と思っていた所
でした。
以上、僕の知っている、Common Lispの近況トピックでしたー。
ひろのぶ
PS.
規模の大きいシステムをOOを使って書くなら、CLOSを使うのが、技術的には、
お奨めなんだけど、なんせ、Lispを書けるプログラマの人口が少ないんで実際
は難しいんだなー。
Hironobu Suzuki
>>>>> "NAKAI" == NAKAI Tetsushi <na...@tsl.pe.u-tokyo.ac.jp> writes:
In article <NAKAI.97O...@tsl.pe.u-tokyo.ac.jp> na...@tsl.pe.u-tokyo.ac.jp (NAKAI Tetsushi) writes:
NAKAI> 個人的印象ですが，オブジェクトのリスト表現ができると3次元物
NAKAI> 体を取扱うのが楽そうです．実際，Robotics の分野の EusLisp もそ
NAKAI> このところがウリに見えますし．
ぼくも同じ意見です。
歴史を辿れば、大昔、といっても１０年ちょい前の話ですが、世界で一番使い
勝手がよくスーパーコンピュータにも負けない高速なレンダリング・システム
は、SymbolicsのLispマシン上にありました。アーキテクチャーの関係で同価
格帯の数値計算コンピュータよりも速い。もちろん、システムはLispで書かれ
ています。
アメリカの大学は、MITだけではなく、アカデミック分野には古くからのLisp
文化がありますから、そこの卒業生が切り開くThe edgeな技術分野、たとえば、
ロボット、グラフィック、高度な制御、その他モロモロなソフトウェアに広範
囲にLisp (CL/CLOS)が使われています。
第五世代コンピュータの影響があって、日本ではLisp人口が少なくなってしまっ
た僕は思っているのですが、それはさておき、Lisp(CL/CLOS)は現役どころで
はなくって、まさに、メモリやチップが安く高速になってきたのと、コンパイ
ラ技術が高度になっているので、今からが旬な言語システムだと僕は思ってい
ます。もうLispを使わなくなって、７、８年経つけど、もう一度使い始めよう
かなーと思っている所です。
ただ、本格的な開発現場では使うのは難しいでしょう。なぜなら、日本には
Lispを使えるソフトウェア技術者が少ないんで、プロジェクトをおこそうにも
人が集まらない。
ひろのぶ
Shinji Kono
河野 真治@琉球大情報工学です。
In article <HIRONOBU.97...@h2np.SpamEater.h2np.suginami.tokyo.jp> ,
hiro...@SpamEater.h2np.suginami.tokyo.jp (Hironobu Suzuki) writes
>勝手がよくスーパーコンピュータにも負けない高速なレンダリング・システム
>は、SymbolicsのLispマシン上にありました。
NHKの「人体」に使われたやつですね。
>第五世代コンピュータの影響があって、日本ではLisp人口が少なくなってしまっ
>た僕は思っているのですが、
これは、そんなことはないと思います。PrologはUnificationのあ
るLISP ですから。それに、majorなAI toolはやはりLISPが多いで
すね。ま、僕は、LISPよりはPrologだけど。
ただ、いかんせん、Common LISPが堅すぎ。あれじゃあ、使う気に
ならない。
Various LISPS ----> Common LISP
では、LISPの特徴の大半を消してしまった気がします。
Interpreter 重視
互換性のある仮想コード
Various LISPS +
Common LISP + Common Runtime Kernel
みたいな形にできなかったのかな? せめて、Reflection でEmacs LISP
をEmulateできるくらいにして欲しかった。
あと、
GC をもっと制御できること
function callが軽いこと
multi-thread
巨大でないObject指向
ぐらいがないといやです。CLOSにはつき合いたくない...
とかいうと、今だったらJavaじゃない?
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
Hironobu Suzuki
>>>>> "Shinji" == Shinji Kono <ko...@ie.u-ryukyu.ac.jp> writes:
In article <4629.87...@rananim.ie.u-ryukyu.ac.jp> ko...@ie.u-ryukyu.ac.jp (Shinji Kono) writes:
Shinji> ただ、いかんせん、Common LISPが堅すぎ。あれじゃあ、使う気にな
Shinji> らない。
逆に、その資質がある程度大きなソフトウェアを開発する上では必要になって
くるんです。
Shinji> とかいうと、今だったらJavaじゃない?
オブジェクト指向の勉強のためのサンプルプログラムや、ディスクトップ上の
GUIとかならJavaでしょう。しかし、まだまだJavaの使用と開発環境は、大規
模なエンタブライズ・コンピューティングを一貫して開発するのに耐えられる
だけのモノにはなっていません。
ちなみに、しっかりとOOPSを教えたり、学んだりするのは、現時点でもJavaを
使用するより、Smalltalkの方が良いと思います。ただし、導入コストの関係
でJavaに軍配はあがりますが。
ところで、前回、話が出たCommon LispでかかれたHTTPサーバのrelase-noteの
一部分を抜粋します。オタメシあれ。
CL-HTTP 60.57 (MCL 2.6.6, ACL 1.10.23, LW 1.2.1 LCL, 4.2.4)
CL-HTTP version 60.57 is now available from the home page and FTP site.
http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
ftp://ftp.ai.mit.edu/pub/users/jcma/cl-http/
The current release is available for:
* MAC running under MCL 4.0 (PowerPC), MCL 3.1 (68k), MCL 3.9
(PowerPC), MCL 3.0 (and MCL 2.0.1 with the usual caveats). Please
report bugs, problems, or suggestions to bug-mac...@ai.mit.edu
* Lisp Machine under Symbolics Genera 8.3 (also Open Genera 1.0)
* UNIX
o Allegro Common Lisp 4.2, 4.3
OS: SunOS 4.1.3x; Solaris 2.4, 2.5, 4.1.3; SGI IRIX 5.3
Please report bugs, problems, or suggestions to
bug-acl...@ai.mit.edu
o LispWorks Common Lisp 3.2.2.
Please report bugs, problems, or suggestions to
bug-lw-...@ai.mit.edu
o Lucid Common Lisp: This port has not been updated for
the present release. -:( Any volunteers who wish to
help out should contact bug-lcl...@ai.mit.edu
However, Lucid users can run CL-HTTP 58.12 until
someone updates the port.
* Windows
o Allegro Common Lisp. Olivier Clarisse has an alphatest
port using a portable threading package. Contact
Oli...@ai.mit.edu for further details. -:)
Hironobu Suzuki
>>>>> "TA" == TANAKA Satoshi <tan...@twcu.ac.jp> writes:
In article <TANAKA.97O...@honeydew-melon.twcu.ac.jp> tan...@twcu.ac.jp (TANAKA Satoshi) writes:
TA> 私も最近またやり始めようと思っているところです。GNUのGUILEによる
TA> Teak(generic desktop interface)やscript-fu(graphics manipulating
TA> interface)が魅力的なので。
いいですねー。それも。
TA> GUILEはCommon Lispじゃなくschemeですし、MLも捨てがたいところだけ
TA> ど...
schemeもいいですねー。好きです。商用Common Lispシステムの提供する開発
環境のようなものがいらなければ、schemeでもぜんぜんＯＫでしょう。
あれ？よく考えたら朱唇は？
朱唇のリカーシブルコール・あたま山の話を聞いた時の衝撃は、今だに忘れま
せん。なんせ、椅子からズリ落ちましたもの。最高です。
ひろのぶ
Yuuji Ichisugi
一杉＠電総研です。
Followup-to: fj.lang.lisp としました。
In article <4629.87...@rananim.ie.u-ryukyu.ac.jp> ko...@ie.u-ryukyu.ac.jp (Shinji Kono) writes:
>これは、そんなことはないと思います。PrologはUnificationのあ
>るLISP ですから。それに、majorなAI toolはやはりLISPが多いで
>すね。ま、僕は、LISPよりはPrologだけど。
Prolog も LISP ですか？？
河野さん、昔、 Perl も lisp だと言ったような気がしますが。
ひょっとして dynamically typed language をぜんぶ lisp と
呼んでいるのでしょうか？
じゃあ、 smalltalk は？ shell script は？
私は、 closure がないと lisp とは言えないと思いますが。
（Ｓ式の構文とか list 処理は本質じゃないと思うけど。）
>あと、
> GC をもっと制御できること
> function callが軽いこと
> multi-thread
> 巨大でないObject指向
>ぐらいがないといやです。CLOSにはつき合いたくない...
>
>とかいうと、今だったらJavaじゃない?
情報処理学１０月号に、「今年の５月に国際標準として成立した ISLISP 」
の話が載ってますが、あれはどうなんでしょうね？
Common Lisp をベースにしたシンプルな lisp 、ということですが。
私も socket と thread くらい仕様に入ってて欲しいと思うのですが、
特にそういう記述はないですね。(^_^;)
そういう点ではやっぱり guile か Java ですか。
ところで、私が lisp が好きなのは、マクロがあるところです。
Java に、 lisp のマクロと同じ拡張性を与えるシステムを作っています。
（http://www.etl.go.jp/etl/bunsan/‾ichisugi/doc/javacon.html）
それを使って Java に lisp の symbol のような機能を入れたのが半年前、
先週は backquote macro を作って、明日は dynamic variable 、
というふうに Java の lisp 化にはげんでます。(^_^)
---
一杉裕志＠電総研 ichi...@etl.go.jp
Hironobu Suzuki
>>>>> "TA" == TANAKA Satoshi <tan...@twcu.ac.jp> writes:
In article <TANAKA.97O...@honeydew-melon.twcu.ac.jp> tan...@twcu.ac.jp (TANAKA Satoshi) writes:
TA> twcu & lisp → 東女 & lisp → 朱唇ってよっぽどのマニアでないと...
実は私、マニアなんです。...というのは実はウソです（...というは実はウソ
です（...というは実はウソです(...)））。
Stack Over Flow.
実は、TWCU出身の研究者の方と知合いなんで、その辺の話を聞いたことがある
んです。その時の印象が、なかなか鮮烈でした。
実際に書いたりしたことはありません。処理系も手に入れていないです。
よく、そーゆー言語処理系で仕様だけ知っているっていうのは、僕の場合、結
構あるんです。日本国内では、北欧で作られた、Simulaの直系子孫BETAなんて
いうのを詳しく知っていたりするのも、滅多にいませんでしたし(ただし、も
う時間が過ぎているので、どんどん記憶の彼方に消えていっていますが）。
それはさておき、日本的な概念で一貫して、きちんと計算機言語を説明したと
いうのは、後にも先にも朱唇ぐらいでしょう。その点、もっと評価されて良い
と思います。
計算機言語オタク
ひろのぶ
PS.
あと、感動といえば、ビジュランがあります。ちなみにビジュランの概要は、
去年か一昨年の老舗コンピュータサイエンス誌Bitに載っています。ビジュラ
ンも、もっと評価されていいと思う。
MURANAKA Masaki
もなもなもなか。
中井＠東大精密さん>
> Common Lisp じゃないけど，Autodesk の作っている AutoCAD はマクロが
>Auto Lisp ではないでしょうか？
そういえば、某社から出ている GUI な計測ツールの裏で Lisp 風のマクロが
うごめいているという話を聞いたことがあります。
(営業から聞いたので信頼性は???ですが。)
また、私が関わった、とある教育関係のシステムでは Lisp 風のマクロで
内容が記述されていました。(car cdr くらいはあった)
表には出てこないところで、かなり使われていそうですね。
--
from もなか
ueh...@po.ntts.co.jp
NTTソフトウェアの上原です。
In article <MONAKA.97O...@ns.inforcom.co.jp> mon...@ns.inforcom.co.jp (MURANAKA Masaki) writes:
～
gccの機種独立な中間コードであるRTLはlispっぽいコードです。
(これをlispとするなら、一番広く使われているlispインタプリタはGCCかも)
古いけど、Interleafというワープロの制御言語はlispだったし、
MEGASOFTの通信ソフト(名前忘れた)のマクロ言語はschemeでしたよね。
--
§ NTTS○FT ニュービジネス事業本部第2プロジェクト 上原 潤二 §
Nobukuni Kino
アイザックの紀と申します。
In article <UEHARA.97O...@gate.po.ntts.co.jp>, ueh...@po.ntts.co.jp writes:
> NTTソフトウェアの上原です。
> [snip]
> gccの機種独立な中間コードであるRTLはlispっぽいコードです。
> (これをlispとするなら、一番広く使われているlispインタプリタはGCCかも)
>
> 古いけど、Interleafというワープロの制御言語はlispだったし、
> MEGASOFTの通信ソフト(名前忘れた)のマクロ言語はschemeでしたよね。
これも昔々の話ですが、ゼロックスの中型機のアセンブラ-MetaSymbol-の
プリプロセッサが(というより正確にはアセンブラ自身ですが)
なかなか強力なものだったですけど、Lispの匂いがしてました。
(その機種を扱っていた某メーカのために)初めてProlog処理系を
書いた時に、普通のアセンブラとLisp風の記述を混ぜて書いて
面白がってみたことを覚えています。
--
(株)アイザック 紀 信邦
ueh...@po.ntts.co.jp
In article <SHIRO.97O...@rhapsody.lava.net>
sh...@lava.net (Shiro KAWAI) writes:
|以前はRTLの外部表現はあくまで参考のためにダンプするだけで、
|それを読み込んでインタプリットするってことはやってなかったと
|思うんですが、最近はそれができるようになったんでしょうか。
GCCの動作時にはその通りですが、
GCC自体のコンパイル時には機械記述(MD, Machine Description)
のRTLを読み込んで処理してますね。*.mdファイルを読むと面白いです。
どっちかというとAWKやPrologなどのパターンマッチ言語に近いです。
Kouichi Kumon
In article <UEHARA.97O...@gate.po.ntts.co.jp> ueh...@po.ntts.co.jp writes:
> gccの機種独立な中間コードであるRTLはlispっぽいコードです。
> (これをlispとするなら、一番広く使われているlispインタプリタはGCCかも)
でも、GCがないですよ。
ユーザがセルの解放を指示していると言えるし、コンスセルもないし、lispと
はちょっと呼べないでしょう。
RTLは見かけをS式に合わせたのです。Stallmanの趣味だとドキュメントのどこ
かに書いてありました。
--
久門耕一＠富士通研究所
ku...@flab.fujitsu.co.jp
代表 044-777-1111