マクロは、ScalaをLISP方言にすることをサポートしていますか？
最近、Scala=でのマクロサポートが公式になりました。 のドキュメントページ を確認したところ、それらを思い出させます 彼のエッセイの1つ で、Paul Grahamは、言語に「この最終的なパワーの増分を追加する」と、それはもはや新しいものですが、LISP方言です。
これはScalaの場合ですか？それは私にとってはLISP方言のようではなく、Scalaでのマクロサポートは私にとっては少し厄介です。
LISP言語ファミリは、あいまいな概念です。主な側面は
- 関数型プログラミングのサポート
- マクロ
- Homoiconic（テキスト<=> The AST、たとえばLISPの括弧への愛）
- 動的に型付け
- 収集されたごみ
Scalaが落ちる大きな場所は3です。Scalaは陽気に同型ではなく、これは必ずしも悪いことではありません。
ただし、これには1つの大きな効果があります。Lispでは、マクロが非常に強力になる理由の1つは、マクロが非常に簡単になることです。一般的なLISPでは、マクロは文字通りリストを返す関数です。それでおしまい。
ScalaまたはHaskell（テンプレートHaskell）では、コンパイル時のメタプログラミングは専門家が行うものであり、LISPではマクロは誰もが行うことです。
Scalaは、静的型付けが非常に強くなる4にも失敗します。ある程度の動的型付けを受け入れるようにコンパイラーを説得できる実用的な方法がありますが、そのときは間違いなく言語と戦っています。
私の考えでは、Scalaは多くの場合と同様にLISPの影響を受けていますが、方言ではありません。
いいえ、Scalaは明らかに意味のある意味でのLISP方言ではありません。彼の言うことを見ると、
私はこれをほとんど冗談として述べていますが、それは事実です。 car、cdr、cons、quote、cond、atom、eq、およびリストとして表現された関数の表記を持つ言語を定義すると、LISPの残りのすべてを構築できます。
したがって、おそらく内部DSLとしても、Scalaに基づいてLISPの方言を書くことができますが、これは、すべてのScalaプログラムがこの方言に属することになるという意味ではありません。
通常はLISPを識別する方法ではありません。ポール・グラハムはここで少し双曲線を描いていると思います。彼はLISPファミリー言語の非常に大きな支持者です（自分で書いた）。
私の知る限り、これらはすべてのLispが共有する一般的な特性の一部です。
- 同型性（コードはデータ、データはコード-これは、LISPプログラムの構造から視覚的に明らかです）
- 動的型付け（おそらくオプションの型注釈を使用）
- すべての関数呼び出しのポーランド表記法（接頭辞のみではなく、接頭辞演算子）
これらの要素から1つ程度の要素を削除しても、言語がLISPファミリに近く、LISPと見なされると主張できる場合があります。一方、Scala：
- 同型ではない（Javaに似た構文を使用）
- 静的に型付けされている
- プレフィックス、インフィックス、ポストフィックスの「演算子」（関数）をサポート
LISPを単に「マクロを備えた言語」であると定義しない限り、Scalaは目的に適合しません。