It is difficult to statically compile code that uses eval, since it could be doing anything at run-time.

Name one. I can't think of any that aren't better served by other constructs.

eval does have one huge, honking problem though: it permits text to be interpreted as code. This is just asking for code injection attacks.

If you really need incremental/multi-stage evaluation, see MetaOCaml (http://www.metaocaml.org/) for the proper way to do it (without exposing yourself to injection vulnerabilities). It's a consequence of PHP's by-the-seat-of-your-pants approach to language design that the PHP devs settled for eval instead.

"Name one. I can't think of any that aren't better served by other constructs."

User input of code. It's hard to implement a REPL without it. Even if you do implement without it there's still an "exec" implementation hiding in there somewhere.

Also, on rare occasions, it is actually an optimization when used carefully, like the Python nametuple example mentioned nearby.

I'm just answering your challenge. I totally agree that in general it's a bad idea and that's an unusual case. While for it to work properly it has to ship with the interpreter, if I were designing a language I would move it out of the global namespace at least, and require some sort of explicit module import with lots of dire warnings in the documentation.

Even in the case of a REPL, what you want isn't "interpret this string as code in the language in which this program is written and apply it to the state of the currently executing program". What you're really looking for is "interpret this string as code in language X and apply it to the state of the given sandbox".

The problem with using eval for a REPL is that you want an interpreter, but eval gives you unprincipled incremental compilation.

Javascript (and I'm sure other languages) is moving in the right direction with sandboxed evals, but those are very difficult to get right in an imperative language, where a lot of code relies on global state (e.g. the DOM). Purely functional languages solve this problem well by disallowing side-effects. Of course there remain the issue of unconstrained resource usage but this is much easier to solve.

User input of code.

I use this in my Python data processing scripts. That is, when I generate data, I generate it as Python literals, either lists or dictionaries. When I have to process it, minimal parsing needed, I just eval it into my code.

  def parse_and_append(line, seq, str):
    if str in line:
        seq.append(eval(line[line.find(str) + len(str):]))

  nums = []
  mappings = {}
  for line in data_file:
    parse_and_append(line, nums, "nums: ")
    parse_and_append(line, mappings, "mappings: ")

Terribly insecure for webpages, sure, but very efficient use of my time.

JSON will let you do that just as well. Or, if you must, there's ast.literal_eval which will only allow Python literals.

I see no reason to use JavaScript to process my data files - keep in mind this is data post-processing of experiments, not a user-facing application. And I enjoy Python, so I'll stick with it. But thanks for the pointer to literal_eval, I have not explored that part of the standard library.

It easier to write an optimizer if you don't use eval since the eval code needs an interpreter.

> [...] since the eval code needs an interpreter.

Or a compiler at run-time.

For some reason, I can't reply to colanderman's comment above/below, but Python's namedtuple is implemented using eval (technically it uses exec, but it's the same idea in Python).