私の友人は、第4回ヨーロッパLispシンポジウムのウェルカムメッセージで私の注意を引きました:
... Common Lisp、Scheme、Emacs Lisp、AutoLisp、ISLISP、Dylan、Clojure、ACL2、ECMAScriptなど、あらゆる Lisp 方言の実装と適用...
次に、ECMAScript が本当に Lisp の方言であるかどうかを尋ねました。本当にそう考えてよいのでしょうか。なんで？
ある言語が Lisp の方言であるかどうかを判断するのに役立つ、明確で明確な一連の基準はありますか? または、非常に大まかな意味での方言です (そして、その場合、Lisp 方言のリストに Python、Perl、Haskell などを追加できますか?)
Brendan Eich は、Netscape 用に Scheme のような言語を作りたがっていましたが、現実が介入し、「普通の」人々にとっては漠然と C や Java のように見えるものの、関数型言語のように機能するものでやり遂げなければなりませんでした。
個人的には、ECMAScript を「Lisp」と呼ぶのは不必要だと思いますが、それぞれ独自のものです。実際の Lisp の重要な点は、データ構造の表記法とコードの表記法が同じであるという特徴のように思われますが、ECMAScript (または Ruby や Python、その他のLisp 以外の動的関数型言語)についてはそうではありません。
警告: 私は Lisp 資格情報を持っていません :-)
そうではありません。それには多くの機能的なルーツがありますが、あなたが指摘したように、今日では他の多くの非 Lisp 言語も同様です。
Lisp には、それらを Lisp にしている 1 つの特徴が残っています。それは、Lisp コードが Lisp データ構造 (ホモイコニシティ) の観点から書かれていることです。これが Lisp の強力なマクロ システムを可能にするものであり、非 Lisp にとって奇妙に見える理由です。関数呼び出しは単なるリストであり、リストの最初の要素が関数の名前です。
Lisp コードは単なる Lisp データであるため、他の言語では実行できない非常に強力な処理をメタプログラミングで行うことができます。多くの Lisp は、clojure のような最新の Lisp でさえも、大部分が一連のマクロとして実装されています。
私は JavaScript を Lisp とは呼びませんが、私の謙虚な意見では、ほとんどの主流言語 (関数型言語でさえ) よりも Lisp のやり方に似ています。
1 つは、Lisp と同じように、本質的に、REPL によって駆動されるのに適した、型指定されていないラムダ計算に基づく単純な命令型言語です。
次に、リテラル データ (ラムダ式の形式のコードを含む) を JavaScript に埋め込むのは簡単です。これは、そのサブセットが JSON と同等であるためです。これは一般的な Lisp パターンです。
第三に、その値と型のモデルは非常にぎこちないです。すべての値にアイデンティティの概念があるという点で、広義のオブジェクト指向ですが、狭義のほとんどのオブジェクト指向ではありません。Lisp と同様に、オブジェクトは型付けされ、非常に動的です。コードは通常、クラスではなく関数の単位に分割されます。
実際、JavaScript の世界には (多かれ少なかれ) いくつかの最近の開発があり、言語がかなりぎこちなく感じられることがあります。たとえば、jQuery を見てみましょう。私の意見では、CSS セレクターをサブ言語として埋め込むことは、かなり Lisp に似たアプローチです。または、ECMAScript Harmony のメタオブジェクト プロトコルを考えてみましょう。これは、Common Lisp の直接のポートのように見えます (Python や Ruby のメタオブジェクト システムよりもはるかに優れています!)。リストは続きます。
JavaScript にはマクロが欠けており、エディターと統合された REPL の賢明な実装が欠けていますが、これは残念なことです。確かに、他の言語からの影響も非常に顕著です (必ずしも悪い意味ではありません)。それでも、Lisp キャンプと JavaScript キャンプの間にはかなりの量の文化的互換性があります。一部は偶然かもしれませんが (最近の JavaScript JIT コンパイルの台頭など)、一部は体系的ですが、確実に存在します。
ECMAScript Lisp を呼び出す場合は、基本的に、すべての動的言語が Lisp であると主張していることになります。私たちはすでに「動的言語」を持っているので、「Lisp」がより具体的な意味を持つことを許可する代わりに、「Lisp」を役に立たない同義語に減らしています。
Lisp は、特定の属性を持つ言語を適切に参照する必要があります。
次の場合、言語は Lisp です。
そのソース コードはツリー構造のデータであり、ネストされたリストとして簡単に印刷された表記があります。考えられるすべてのツリー構造は、対応する表記法でレンダリングされ、構造として意味を与えられやすいです。言語を拡張するために表記自体を拡張する必要はありません。
ツリー構造のデータは、言語自体の主要なデータ構造であり、プログラムがプログラムによって操作されやすくなります。
言語には記号データ型があります。記号には、インターンされた印刷表現があります。記号の同じ印刷表記の 2 つ以上のインスタンスが表記に現れる場合、それらはすべて同じオブジェクトを示します。
a、その構文aはシンボル オブジェクトであり、文字列"a"ではありません。文字列は、表示用のシンボルの名前にすぎません。変数への参照、aつまりプログラムの他の場所で記述された式も on オブジェクトです。シンボルの動作方法により、これは同じオブジェクトです。このオブジェクトの同一性は、参照を定義に結び付けます。オブジェクトの同一性は、ポインターの等価性として実装される場合があります機械レベルで。2 つのシンボル値が同じであることは、ヒープ (シンボル型のオブジェクト) 内の同じメモリ位置へのポインターであるためです。そして、私はそこで止まります。一部の人々は、Lisp システムは対話型でなければならない、と信じています: すべてが変更可能で、いつでも再定義できるリスナーを備えた環境を提供するなどです。Lisp には第一級の関数が必要だと考える人もいます:lambda演算子などが必要です。car頑固な伝統主義者は、 andcdr関数、不適切なリストをサポートするドット ペア表記法が必要であり、リストはセルで構成され、特にnil空のリストを示す記号とブール値 falseで終了する必要があると主張することさえあります。Scheme が Lisp であることを主張しcar、それを許可するが、リスト ターミネータであり、誤った規則であるcdrnil
しかし、「Lisp の方言」の定義を掘り下げれば掘り下げるほど、それはより政治的なものになります。人々は、お気に入りの方言 (おそらく自分で作成したもの) が何らかの専門性のために除外されていることに腹を立てます。主張しcar、cdrScheme が Lisp であることを許可しますnilが、リスト ターミネータであり false であることは、それを除外します。なに、Scheme は Lisp じゃないの？
したがって、上記に基づくと、ECMAScript は Lisp の方言ではありません。ただし、ECMAScript の実装には、Lisp の方言として公開できる機能が含まれており、そのような方言が多数開発されています。何らかの感情的な理由で ECMAScript を Lisp と見なす必要がある人は、おそらくそれに満足する必要があります: Lisp をサポートするセマンティクスが存在し、ECMAScript で開発でき、相互運用できるそのセマンティクスへの適切なインターフェイスが必要なだけです。 ECMAScript コードを使用します。
いいえ、ちがいます。
Lisp と見なされるためにはホモイコニックでなければなりませんが、ECMAscript はそうではありません。
「方言」ではありません。LISP は 70 年代に学び、それ以来使っていませんでしたが、最近 JavaScript を学んだとき、LISP のようなものだと思っていました。これは 2 つの要因によるものだと思います。(1) JSON はリストのような連想構造であり、(2) JS の「オブジェクト」は本質的に JSON であるかのようです。したがって、リストで LISP を記述するように JSON で JS プログラムを記述しなくても、ほぼそうします。
だから私の答えは、LISP に精通しているプログラマーが JavaScript を使用するときにそれを思い出すのに十分な類似点があるということです。Java スーツの JS = LISP のようなステートメント は、その感覚を表現しているだけです。それだけだと思います。
はい、そうです。クロックフォードの引用：
「JavaScript は、Scheme と多くの共通点があります。これは動的言語です。S 式を簡単にシミュレートできる柔軟なデータ型 (配列) を備えています。そして最も重要なことは、関数がラムダであることです。
この深い類似性により、[再帰プログラミングの入門書] 'The Little Schemer' の関数はすべて JavaScript で記述できます。"
http://www.crockford.com/javascript/little.html
同性愛については、JavaScript と一緒にその単語を検索することをお勧めします。「ホモイコニックではない」と言うのは本当ですが、話の終わりではありません.
英語がフランス語の方言であるのと同じ意味で、ECMAScript は LISP の方言だと思います。共通点はありますが、一方が他方の知識だけで武装していると、割り当てに問題が生じるでしょう :)
第 4 回ヨーロッパ Lisp シンポジウムでハイライトされた 3 つの基調講演のうち 1 つだけが Lisp に直接関係していることは興味深いと思います (残りの 2 つは x86/JVM/Python と Scala に関するものです)。
「方言」は間違いなくそれを伸ばしすぎています。それでも、Python、Javascript、Scheme を学び、使用したことのある人として、Javascript は明らかに Python よりもはるかに Lisp 寄りの感覚を持っています (Coffeescript はおそらくそれ以上です)。
ヨーロッパの Lisp シンポジウムが Javascript を Lisp として描写したい理由については、明らかに彼らは Javascript の人気に便乗したいのです。Javascript のプログラマ人口は、彼らのリストにある他のすべての Lisp 方言を合わせた数よりも何倍も多くなっています。 .