ECMAScriptは本当にLispの方言ですか？
私の友人が私の注意を引いた 第4回ヨーロッパLISPシンポジウム ：
... Common LISP、Scheme、Emacs LISP、AutoLisp、ISLISP、Dylan、Clojure、ACL2、ECMAScript、..を含むLISPダイアレクトの実装とアプリケーション.
次に、ECMAScriptが本当にLISPの方言であるかどうかを尋ねました。それは本当にそう考えることができますか？どうして？
言語がLispの方言であるかどうかを検出するのに役立つ、明確に定義された明確な基準のセットはありますか？または、非常に緩い意味で解釈されている方言です（その場合、Python、Perl、HaskellなどをLISP方言のリストに追加できますか？）
ブレンダン・アイクはNetscapeでSchemeのような言語を使いたいと思っていましたが、現実が介入し、Cと漠然とに見えるものを使わなければならなくなりました。 Java "普通の"人向けですが、関数型言語のように機能しました。
個人的には、ECMAScriptを「LISP」と呼ぶのは不必要なことだと思いますが、それぞれ独自のものです。実際のLISPの重要な点は、データ構造表記とコード表記が同じであるという特徴のようですが、ECMAScript（またはRubyまたはPython =またはnotLISP）であるその他の動的関数型言語。
警告：私はLISP資格情報を持っていません:-)
そうではありません。それは多くの機能的ルーツを持っていますが、あなたが指摘したように、今日では他の多くの非LISP言語もそうです。
Lispには、Lispを作成する1つの特徴が残っています。それは、LISPコードがLISPデータ構造（同像性）の観点から記述されていることです。これが、Lispの強力なマクロシステムを可能にするものであり、Lisp以外の人には非常に奇妙に見える理由です。関数呼び出しは単なるリストであり、リストの最初の要素は関数の名前です。
LISPコードは単なるLISPデータであるため、メタプログラミングを使用して非常に強力な処理を実行できます。これは、他の言語では実行できません。多くのLispは、clojureのような最新のものでさえ、マクロのセットとしてそれ自体で主に実装されています。
私はJavaScriptをLISPとは呼びませんが、私の謙虚な意見では、ほとんどの主流言語（機能的な言語でさえ）よりもLISPのやり方に似ています。
1つは、LISPと同じように、本質的には、REPLによって駆動されるのに適した、型指定されていないラムダ計算に基づく単純な命令型言語です。
次に、JavaScriptにリテラルデータ（ラムダ式の形式のコードを含む）を埋め込むのは簡単です。これは、そのサブセットがJSONと同等であるためです。これは一般的なLISPパターンです。
第三に、その値と型のモデルはvery lispyです。すべての値がアイデンティティの概念を持っているという点で、Wordの広い意味でのオブジェクト指向ですが、Wordの最も狭い意味でのオブジェクト指向ではありません。 LISPの場合と同様に、オブジェクトは型指定され、非常に動的です。コードは通常、クラスではなく関数の単位に分割されます。
実際、JavaScriptの世界には、言語がときどきかなり甘美に感じられるようにする（多かれ少なかれ）最近の開発がいくつかあります。 jQueryを例にとってみましょう。私の意見では、CSSセレクターをサブ言語として埋め込むことは、かなりLISPのようなアプローチです。または、ECMAScript Harmonyのメタオブジェクトプロトコルを検討してください。これは、Common LISPの直接ポートのように見えます（PythonまたはRubyのメタオブジェクトシステムよりもはるかに優れています！）。リストは続きます。
JavaScriptにはマクロがなく、REPLエディター統合による賢明な実装です。これは残念です。確かに、他の言語からの影響も非常に目立ちます（必ずしも悪い方法ではありません）。それでも、LISPキャンプとJavaScriptキャンプの間にはかなりの文化的互換性があり、偶然の一致（JavaScript JITコンパイルの最近の台頭など）や体系的なものもありますが、間違いなく存在します。
いいえ、ちがいます。
LISPと見なされるためには、同像性である必要がありますが、ECMAscriptはそうではありません。
ECMAScript LISPを呼び出す場合、基本的に、動的言語はすべてLISPであると主張しています。すでに「動的言語」があるので、「LISP」をより具体的な意味を持つのではなく、役に立たない同義語に減らしています。
LISPは、特定の属性を持つ言語を適切に参照する必要があります。
次の場合、言語はLISPです。
そのソースコードはツリー構造のデータであり、ネストされたリストとして簡単に印刷された表記法があります。考えられるすべてのツリー構造には、対応する表記法でのレンダリングがあり、構成概念としての意味が与えられやすいです。言語を拡張するために表記自体を拡張する必要はありません。
ツリー構造のデータは、言語自体の主要なデータ構造であるため、プログラムはプログラムによる操作の影響を受けやすくなります。
言語にはシンボルデータ型があります。シンボルには、internedである印刷表現があります。シンボルの同じ印刷表記の2つ以上のインスタンスが表記に表示される場合、それらはすべて同じを示します。オブジェクト。
- シンボルオブジェクトの主な長所は、他のすべてのシンボルとは異なることです。シンボルは、LISPプログラムのセマンティクスでさまざまな方法で他のさまざまなエンティティとペアになり、それによってそれらのエンティティの名前として機能します。
- たとえば、LISPの方言には通常、他の言語と同じように変数があります。 LISPでは、変数はテキスト名ではなく記号（メモリ内のオブジェクト）で示されます。 LISPプログラムの一部が変数
aを定義している場合、そのaの構文はシンボルオブジェクトであり、文字列"a"、これは印刷を目的としたそのシンボルの名前です。プログラムの他の場所でaとして記述された式である変数への参照も、onオブジェクトです。シンボルの動作方法のため、それは同じオブジェクトです。このオブジェクトの同一性により、参照が定義に接続されます。オブジェクトの同一性は、マシンレベルでポインタの同等性として実装される場合があります。 2つのシンボル値は、ヒープ内の同じメモリ位置（シンボルタイプのオブジェクト）へのポインタであるため、同じであることがわかっています。 - 適切な例： ネストされたリストを含むほとんどのデータ型の非従来型のメモリ管理 を持つNewLisp方言は、シンボルを上記のように動作させることにより、シンボルの例外を作成します。これがなければ、LISPにはなりません。引用： "newLISP内のオブジェクト（シンボルとコンテキストを除く）は、値のコピーによって他のユーザー定義関数に渡されます。その結果、各newLISPオブジェクトは1つの参照のみを必要とします。 "[私の強調]。値のコピーのようにシンボルも渡すと、そのIDが破壊されます。シンボルを受け取る関数は元のシンボルを取得しないため、そのIDを正しく受け取りません。
- LISP言語の複合式（数値や文字列のような単純なプライマリではないもの）は、単純なリストで構成され、その最初の要素は操作を示す記号です。残りの要素は、もしあれば、引数式です。 LISP方言は、ある種の評価戦略を適用して、式を値に減らし、それが持つ可能性のある副作用を引き起こします。
- 私は暫定的に値のペアを保持するバイナリセルで作成され、特別な空のリストオブジェクトで終了するリストは、おそらくその一部と見なされるべきであると主張しますLISPの定義：新しいアイテムを前面に「コンシング」することで既存のリストから新しいリストを作成できるというビジネス全体、およびリストの「最初」と「残り」での簡単な再帰など。オン。
そして、私はそこで止まります。一部の人々は、LISPシステムはインタラクティブでなければならないと考えています。リスナーを備えた環境を提供します。リスナーはすべてが可変であり、いつでも再定義できます。 Lispにはファーストクラスの関数が必要であると考える人もいます。つまり、lambda演算子などが必要です。頑固な伝統主義者は、car関数とcdr関数、不適切なリストをサポートする点線のペア表記、およびリストはセルで構成され、具体的には記号で終了する必要があると主張することさえあります。 nilは空のリストを示し、ブール値はfalseです。 carとcdrを主張することで、SchemeをLISPにすることができますが、nilはリストターミネーターであり、誤ったルールです。
しかし、「LISP方言」の定義を深く掘り下げるほど、それは政治的になります。人々は、自分の好きな方言（おそらく自分で作成した方言）が技術的に除外されていることに腹を立てます。 carとcdrを主張することで、SchemeをLISPにすることができますが、nilはリストターミネーターであり、falseはそれを除外します。なに、SchemeはLispではないのですか？
したがって、上記に基づくと、ECMAScriptはLISPの方言ではありません。ただし、ECMAScriptの実装には、LISP方言として公開できる機能が含まれており、 このような方言が多数開発されています 。感情的な理由でECMAScriptをLISPと見なしたい人は、おそらくそれに満足しているはずです。LISPをサポートするセマンティクスがあり、ECMAScriptで開発でき、相互運用できるそのセマンティクスへの適切なインターフェイスが必要です。 ECMAScriptコードを使用します。
「方言」ではありません。私は70年代にLISPを学び、それ以来使用していませんが、最近JavaScriptを学んだとき、それはLISPに似ていると思いました。これは2つの要因によるものだと思います。（1）JSONはリストのような連想構造であり、（2）JSの「オブジェクト」は本質的にJSONであるように見えます。したがって、リストでLISPを作成する場合のように、JSONでJSプログラムを作成しなくても、ほとんど作成します。
だから私の答えは、LISPに精通しているプログラマーがJavaScriptを使用するときにそれを思い出させるのに十分な類似点があるということです。 JS = LISP in a Java suiteのようなステートメントは、その気持ちを表現しているだけです。それだけだと思います。
ECMAScriptは、英語がフランス語の方言であるのと同じ意味で、LISPの方言だと思います。共通点はありますが、一方の武装ではもう一方の知識だけで割り当てに問題が発生します:)
第4回ヨーロッパLISPシンポジウムで強調された3つの基調講演のうち1つだけがLISPに直接関係していることは興味深いと思います（他の2つはx86/JVM/PythonとScalaに関するものです）。
「方言」は間違いなくそれを過度に伸ばしています。それでも、Python、Javascript、Schemeを学び、使用したことのある人として、Javascriptは明らかにPythonよりもはるかにLISPっぽい感じがします（そしてCoffeescriptはおそらくもっとそうです）。
欧州のLISPシンポジウムがJavascriptをLISPとして表現したいと思う理由については、明らかに、プログラマーの人口が多く、リスト内の他のすべてのLISP方言を合わせたものよりも何倍も多いJavascriptの人気に便乗したいと考えています。 。
はい、そうです。 Crockfordの引用：
「JavaScriptはSchemeと多くの共通点があります。動的言語です。S式を簡単にシミュレートできる柔軟なデータ型（配列）があります。そして最も重要なのは、関数がラムダです。
この深い類似性のために、[再帰的プログラミング入門書]「TheLittleSchemer」のすべての関数はJavaScriptで記述できます。」
http://www.crockford.com/javascript/little.html
同像性については、JavaScriptと一緒にその単語を検索することをお勧めします。それが「同像性ではない」と言うことは真実ですが、話の終わりではありません。