「ラムダ・ザ・アルティメット」の語源と意味は何ですか？
私は数年前から関数型プログラミング言語をいじっていて、このフレーズに出会います。たとえば、これは「リトルスキーマー」の章で、確かにこの名前よりも古いブログです（いいえ、この章は私の質問への回答には役立ちません）。
私はラムダの意味を理解しています。無名関数の概念は単純で強力ですが、このコンテキストでの「究極」の意味を理解できません。
私がこのフレーズを見た場所：
- The Little Schemerの第8章のタイトル
- ブログ： http://lambda-the-ultimate.org/
- 一連の「究極のXラムダ」論文： http://library.readscheme.org/page1.html
私はここで参照が欠落しているように感じます、誰かが助けてもらえますか？
はい、これは、70年代のカップルから始まって、いくつかの論文のタイトルに繰り返し現れるフレーズです。SussmanとSteeleは、「 Scheme）という名前の最小限のLISP方言を使用して、プログラミングにラムダ計算を使用していることを示しています。 "彼らは目的のために考案しました。あなたは見つけることができます ここの論文自体 ;それらは興味深く、驚くほど関連性があります。
これが明示的に述べられているかどうかはわかりませんが、（文脈から、論文を読んで、著者の一般的な背景と研究の関心を知って）ラムダ抽象化という主張に対する単なるキャッチーなスローガンであることは明らかですは、計算プリミティブとして、形式的な意味で普遍的である（何らかの方法でプログラムをエンコードできるが、扱いにくい）だけでなく、実用的な他の言語に存在するすべての構成要素は、ゼロから組み込まれているものであっても、効果的かつ自然に使用できる方法でラムダベースの言語で再実装できることを理解してください。
繰り返されるフレーズは、「すべてのXにとって、ラムダは究極のXである」という明白な一般化された形式につながります。これは、「ラムダザアルティメット」をブログ名として一般的に捉えた意味であり、LtUはプログラミング言語に関係していることに注意してくださいデザインと理論。皮肉なことに、LtUはおそらく、ラムダがではない究極の実装である何かについてあなたに話すことができる誰かを見つけるのに最適な場所の1つでしょう。 ：]
また、Sussmanは [〜＃〜] sicp [〜＃〜] の作成者の1人であり、Scheme言語も使用し、ラムダ抽象化を導入するのにかなりの時間を費やしています。コンセプト。
Lambda The Ultimateは、lambda-calculusのラムダが効果的にすべてのプログラミング言語の組み込み概念everyを実装できるという考え方を過去のものにしています、現在、そして未来。クラス、モジュール、パッケージ、オブジェクト、メソッド、制御フロー、データ構造、マクロ、継続、コルーチン、ジェネレーター、リスト内包表記、ストリームなど。
偶然にも、その究極の性質には、匿名関数を表すが含まれます。しかし、ラムダは、本質的に、匿名関数だけに限定されていません。彼らはそのように教えられますが、ラムダの本質は、名前のない数学関数よりもはるかに深くなります。言い換えれば、私は次の問題を取り上げます：
私はラムダの意味を理解しています。無名関数の概念は単純で強力ですが、この文脈での「究極の」の意味を理解できません。
実際問題として、構文の抽象化（ 'マクロ'）としてラムダを使用することは、値による呼び出し/適用（数学関数ではありません）ではなく、非常に重要ですラムダは本当にすべてのプログラミング言語処理システムの中核として機能することができるという考えに賛同します。
理論について：ナイーブセット理論には、バートランドラッセルのパラドックスと理解の公理（および拡張）との興味深い関係があります。ラムダとは、関数に対するセットビルダー表記とは何ですか。ラムダとは、関数ビルダー表記です。 （lambda（x）（* x x））と評価されるもの（二乗する関数）の間には、通常は無視される重要な違いがあります。一般に2つを区別できない場合、つまり表記と表示（ChurchとFregeの両方が犯した間違い）を区別できない場合、パラドックスに陥ります。セットとフレゲの場合、エラーを示すのはベルトランドラッセルのセビリアの理髪師です。機能と教会のために、それはアラン・チューリングの停止オラクルです。
パラドックスは良い、実用的なものであることに注意してください。 EVALを表現可能にし、ラムダは単なる関数以上のものを意味します。反対が矛盾につながると仮定することは望ましい結果です。これはニースの正気度テストとして機能します。ラムダは、単なる関数を表すだけの場合、最終的なものになることはほとんどありません。
ラケット （以前のPLTスキーム）は、実用的なプログラミング言語を「ラムダだけ」で根本から構築できるという考えを訴え続けています。
カーネル 、Shuttによると、ラムダは実際には究極の抽象概念ではないと主張しています。彼はSussmanにFEXPRとして知られていた、より原始的な概念（ギリシャ語では吹き替え型のvau）がまだあると主張しています。
Felleisinと会社（ラケットの場合）は、phases、またはメタレベルの概念を使用して、Shuttのvauの能力の多くを取得します。前処理Cの場合と同様ですが、各「ステップ」で同じ言語を使用し、「ステップ」は実際には時間的に完全に区別されるわけではありません）。 （したがって、より高いフェーズのラムダは十分にvauに近いと主張します。）実際、フェーズがFEXPRよりも良いと主張します。要するに、「FEXPRは非常に強力です」（Shuttが主張するWandの研究を参照）。
ブライアン・スミスの3-LISP、「プログラミング言語における手続き的反映」は、表記（シンボル/言語/プログラム）と表記（もの/リファーレント/値/結果）を明確に区別する線に沿って、LISPに似た言語の理論を厳密に再構成しようとしています。 ）。 http://dspace.mit.edu/handle/1721.1/15961
ミッチェルワンドの「The Fory of FEXPRs is Trivial」は、ケントピットマンがFEXPRのために作成した（一時的な？）棺に釘を送ります（Felleisenのように、FEXPRに対してコンパイルが複雑すぎると主張しています）。
Paul Grahamは、 "On LISP"において、真の力は値の変換器（数学関数）ではなく、構文の変換器（マクロ）としてのラムダであると強く主張しています。プロトキンがアプリケーションのラムダ計算の開発をやや対照的と見なすことができるのは、プロトキンがチャーチの計算をその値による呼び出し/適用サブセットに制限しているためです。もちろん、アプリケーション部分を効率的に処理することは非常に重要であるため、ラムダの使用に特化した理論を開発することが重要です。 （プロトキンとグラハムは互いに反対しません。）
実際、一般に、ラムダを究極のものとする概念は、効率と表現力の間の永遠の議論に対するそのようなひねりの1つにすぎません。これは、ラムダが表現力の究極のツールであり、十分な研究を経て、最終的には効率の究極のツールであることが証明されるという立場です。言い換えれば、私たちが望むなら、プログラミング言語の将来を、ラムダ計算の実際に関連するすべてのフラグメントを効率的に実装する方法の研究にすぎないと見なすことができます。
Landinの「The Next 700 Programming Languages」 http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf は、その開発に貢献するアクセス可能なリファレンスですラムダが究極だというコンセプト。
1975年から1980年の間にSussmanとSteeleによって書かれたいくつかの論文への言及にすぎないと思います。
- ラムダ：究極の命令
- ラムダ：究極の宣言
- ラムダ：究極のGOTO
- LAMBDA：究極のオペコード