なぜeval evilなのか？

LispとSchemeのプログラマーは、eval厳密に必要な場合を除いて、通常はそれを避けるべきだと言っています。いくつかのプログラミング言語について同じ推奨事項を見てきましたが、の使用に対する明確な議論のリストはまだ見ていませんeval。使用の潜在的な問題の説明はどこにありますかevalか？

たとえば、私GOTOは手続き型プログラミングの問題を知っています（プログラムが読み取りにくくなり、保守が困難になり、セキュリティの問題が見つけにくくなるなど）。しかし、eval。

興味深いことに、GOTO継続に対しても同じ議論が当てはまるはずですが、たとえば、Schemersは継続が「悪」だとは言っていないようです。使用する場合は注意が必要です。彼らはeval継続を使用するコードよりもコードを使用するほうが眉をひそめる可能性がはるかに高いです（私が見る限り、私は間違っている可能性があります）。

使用すべきでない理由はいくつかありますEVAL。

初心者の主な理由は、あなたがそれを必要としないことです。

例（Common Lispを想定）：

異なる演算子を使用して式を評価します。

(let ((ops '(+ *)))
  (dolist (op ops)
    (print (eval (list op 1 2 3)))))

それは次のように書く方が良いです：

(let ((ops '(+ *)))
  (dolist (op ops)
    (print (funcall op 1 2 3))))

Lispを学ぶ初心者EVALが必要だと考える例はたくさんありますが、式は評価され、関数の部分も評価できるため、必要ではありません。ほとんどの場合、の使用はEVAL評価者の理解の欠如を示します。

マクロでも同じ問題です。多くの場合、初心者は関数を書くべき場所でマクロを書く-マクロが本当に何のためにあるのかを理解しておらず、関数がすでに仕事をしていることを理解していない。

それはしばしばジョブが使うための間違ったツールでありEVAL、それはしばしば初心者が通常のLisp評価ルールを理解していないことを示しています。

あなたが必要と考えられる場合はEVAL、何かのような場合は、チェックFUNCALL、REDUCEまたはAPPLY代わりに使用することができます。

• FUNCALL -引数を指定して関数を呼び出します。 (funcall '+ 1 2 3)
• REDUCE -値のリストに対して関数を呼び出し、結果を結合します。 (reduce '+ '(1 2 3))
• APPLY-リストを引数として関数を呼び出します(apply '+ '(1 2 3))。

Q：私は本当にevalを必要としますか、それともコンパイラ/エバリュエータはすでに私が本当に望んでいるものですか？

EVALやや上級のユーザーには避けるべき主な理由：

• コンパイラはコードの多くの問題をチェックし、より高速なコードを生成できるため、コードがコンパイルされていることを確認したい場合があります。

• 構築され、評価が必要なコードは、できるだけ早くコンパイルできません。

• 任意のユーザー入力を評価すると、セキュリティの問題が発生します

• 評価の一部の使用はEVAL、間違ったタイミングで発生し、ビルドの問題を引き起こす可能性があります

簡単な例で最後のポイントを説明するには：

(defmacro foo (a b)
  (list (if (eql a 3) 'sin 'cos) b))

したがって、最初のパラメーターに基づいてSINまたはを使用するマクロを記述したい場合がありますCOS。

(foo 3 4)し(sin 4)、(foo 1 4)します(cos 4)ます。

今私たちは持っているかもしれません：

(foo (+ 2 1) 4)

これは望ましい結果を与えません。

次にFOO、変数をEVALuateすることでマクロを修復することができます。

(defmacro foo (a b)
  (list (if (eql (eval a) 3) 'sin 'cos) b))

(foo (+ 2 1) 4)

しかし、これはまだ機能しません：

(defun bar (a b)
  (foo a b))

変数の値は、コンパイル時には不明です。

避けるべき一般的な重要な理由EVAL：醜いハッキングによく使用されます。

eval（どの言語でも）チェーンソーが邪悪ではないのと同じように邪悪ではありません。ツールです。これは、誤って使用すると手足を切断して内臓を取り除くことができる（比喩的に言えば）強力なツールですが、プログラマーのツールボックスにある多くのツールについても同じことが言えます。

• goto と友達
• ロックベースのスレッド化
• 継続
• マクロ（hygenicまたはその他）
• ポインタ
• 再起動可能な例外
• 自己変更コード
• ...そして何千人ものキャスト。

これらの強力で潜在的に危険なツールのいずれかを使用する必要があることに気付いた場合、「なぜですか」と3回尋ねます。チェーンで。例えば：

「なぜ使用しなければならないのevalですか？」「fooのため」「なぜfooが必要なのですか？」「……だから」

そのチェーンの最後に到達しても、ツールがまだ正しいように見える場合は、実行してください。それから地獄を文書化します。それから地獄をテストします。正確性とセキュリティを何度も何度も再確認します。しかしそれをしなさい。

何が入っているかを正確に知っている限り、評価は問題ありません。その中に入るユーザー入力はすべてチェックおよび検証されなければなりません。100％確実にする方法がわからない場合は、行わないでください。

基本的に、ユーザーは問題の言語の任意のコードを入力でき、実行されます。彼がどれほどのダメージを与えることができるか想像してみてください。

「いつ使うべきevalですか？」より良い質問かもしれません。

簡単に言えば、「プログラムが実行時に別のプログラムを作成してから実行する場合」です。遺伝的プログラミングは、使用することが理にかなっていると思われる状況の例ですeval。

IMO、この質問はLISPに固有のものではありません。これはPHPに対する同じ質問に対する回答であり、LISP、Ruby、および評価のある他の言語に適用されます。

eval（）の主な問題は次のとおりです。

• 安全でない可能性のある入力。信頼できないパラメータを渡すことは失敗する方法です。多くの場合、パラメーター（またはその一部）が完全に信頼されていることを確認するのは簡単なことではありません。
• トリッキーネス。eval（）を使用すると、コードが巧妙になるため、理解が難しくなります。Brian Kernighanの言葉を引用すると、「デバッグは、最初にコードを書くよりも2倍困難です。したがって、コードをできる限り巧妙に書くと、当然のことながら、デバッグするほど賢くありません」

eval（）の実際の使用に関する主な問題は1つだけです。

• 十分な考慮なしにそれを使用する経験の浅い開発者。

ここから撮影。

トリッキーな作品は素晴らしいポイントだと思います。ゴルフと簡潔なコードへの執着は常に「賢い」コードをもたらしました（evalは素晴らしいツールです）。しかし、読みやすさのためにコードを書く必要があります。IMOは、自分が賢いことを証明したり、紙を節約したりしないことです（とにかく印刷することはありません）。

次に、LISPにはevalが実行されるコンテキストに関連するいくつかの問題があるため、信頼できないコードはより多くのものにアクセスできます。この問題はとにかくよくあるようです。

多くの素晴らしい答えがありましたが、ここにラケットの実装者の一人であるマシュー・フラットからの別の見解があります：

http://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html

彼はすでにカバーされているポイントの多くを作りますが、それでもそれでも興味深いことに彼のテイクを見つける人もいます。

概要：それが使用されるコンテキストはevalの結果に影響を与えますが、プログラマーによって考慮されないことが多く、予期しない結果につながります。

正解は近づかないことです。それはプリミティブであり、7つのプリミティブ（他はcons、car、cdr、if、eq、quote）であるため、私は奇妙なことに気づきます。

On Lispから：「通常、evalを明示的に呼び出すことは、空港のギフトショップで何かを購入するようなものです。

では、いつevalを使用するのですか？通常の用途の1つは、を評価してREPL内にREPLを含めること(loop (print (eval (read))))です。誰もがその使用法で大丈夫です。

ただし、evalとバッククォートを組み合わせることで、コンパイル後に評価されるマクロに関して関数を定義することもできます。あなたが行く

(eval `(macro ,arg0 ,arg1 ,arg2))))

そしてそれはあなたのために文脈を殺します。

スワンク（emacsスライムの場合）は、これらのケースでいっぱいです。彼らはこのように見えます：

(defun toggle-trace-aux (fspec &rest args)
  (cond ((member fspec (eval '(trace)) :test #'equal)
         (eval `(untrace ,fspec))
         (format nil "~S is now untraced." fspec))
        (t
         (eval `(trace ,@(if args `(:encapsulate nil) (list)) ,fspec ,@args))
         (format nil "~S is now traced." fspec))))

汚いハックだとは思わない。私はいつもそれを使って、マクロを関数に再統合しています。

Lisp evalに関する別のポイント：

• ローカル環境を失い、グローバル環境下で評価します。
• 場合によっては、読み取りマクロ「＃」を実際に使用するつもりであるのに、evalを使用したくなることがあります。これは読み取り時に評価されます。

GOTOの「ルール」のように：自分が何をしているかわからない場合は、混乱させることができます。

既知の安全なデータから何かを構築するだけでなく、一部の言語/実装ではコードを十分に最適化できないという問題があります。あなたは内部で解釈されたコードで終わるかもしれませんeval。

評価は安全ではありません。たとえば、次のコードがあるとします。

eval('
hello('.$_GET['user'].');
');

これで、ユーザーがサイトにアクセスし、http： //example.com/file.php？user =）; $ is_admin = true; echo（

次に、結果のコードは次のようになります。

hello();$is_admin=true;echo();

評価は悪ではありません。評価は複雑ではありません。渡したリストをまとめる関数です。他のほとんどの言語では、任意のコードをコンパイルすることは、言語のASTを学習し、コンパイラの内部を調べてコンパイラAPIを理解することを意味します。LISPでは、evalを呼び出すだけです。

いつ使用すべきですか？何かをコンパイルする必要があるときはいつでも、通常、実行時に任意のコードを受け入れ、生成または変更するプログラム。

いつそれを使うべきではないのですか？他のすべての場合。

必要のないときに使用しない方がいいのはなぜですか。読みやすさ、パフォーマンス、デバッグに問題を引き起こす可能性のある、不必要に複雑な方法で何かをしているためです。

ええ、でも、もし私が初心者なら、それを使うべきかどうかどうやって知るのですか？関数で必要なものを常に実装するようにしてください。それが機能しない場合は、マクロを追加します。それでも機能しない場合は、eval！

これらのルールに従ってください。evalで悪を行うことは決してありません:)

好き ザックの答えがとても好きで、彼は問題の本質に達しました。evalは、新しい言語、スクリプト、または言語の変更を書いているときに使用されます。彼はこれ以上説明しないので、例を挙げましょう。

(eval (read-line))

この単純なLispプログラムでは、ユーザーは入力を求められ、入力した内容が評価されます。これが機能するために全体のシンボル定義のセットを、あなたがそれらすべてを含める必要がありますので、ユーザは、入力した可能性がある機能見当がつかないので、プログラムがコンパイルされた場合に存在しなければなりません。つまり、この単純なプログラムをコンパイルすると、結果のバイナリは巨大になります。

原則として、このため、これをコンパイル可能なステートメントと見なすこともできません。一般に、evalを使用すると、インタプリタ環境で動作しているため、コードをコンパイルできなくなります。evalを使用しない場合は、Cプログラムと同じようにLispまたはSchemeプログラムをコンパイルできます。したがって、evalの使用をコミットする前に、インタープリター環境にいる必要があることを確認する必要があります。