Eval Feature

A feature provided in many programming languages (JavaScript, ToolCommandLanguage, ForthLanguage, many other scripting languages, all modern dialects of LispLanguage) wherein functions expressed as AbstractSyntaxTrees or as text (in the concrete syntax of the language) may be provided to the execution engine/runtime and executed.

Quite easy to implement in HomoiconicLanguages, though certainly not limited to these. Generally requires that the language runtime include a (minimal) compiler/interpreter for the language as part of its definition.

Advantages of having EvalFeature around:

Makes many forms of MetaProgramming much easier.
Can take the place of many other more specialized program transformations/capablilites (such as class loaders, DllImport?, etc.)
For a DynamicLanguage, often trivial to implement.

Disadvantages of EvalFeature:

Often times, it's slow, especially if the executable form of the language is a VirtualMachine (or the native machine code of a CPU). Either you have to switch to a (slower) interpreter which runs on AbstractSyntaxTrees or on raw program text, or you have to compile the thing to the "preferred" form. (That said, a smart implementation will only do this once for a given dynamic function)
Can be a BIG security hole, if untrusted code ever gets passed to eval.
The presence of eval makes many program analyses and ProgramTransformation?s (such as TypeInference, and numerous other optimizations) undecidable - at least as far as the "dynamic" code is concerned; this undecidability may leak into the "static" portions of the code as well.
Many uses of "eval" can be handled by other means (compile-time macros, ParametricPolymorphism, first-class functions, etc.) The uses that can't (such as executing code fragments provided by the user) are probably a bad idea to begin with.
- Balderdash. The claim that executing dynamically generated code is "bad" is simply personal opinion. Eval, as used here, is simply shorthand for the mechanism that performs (pun intended) this operation. A host of applications demand executing dynamically generated code. Some form of eval is needed for each of them.
  - Balderdash. Applications that demand dynamically generated code very rarely require the 'EvalFeature'. Runtime construction of first-class functions or procedures can fill this role the vast majority of the time... all without need to maintain or offer access to variables in the runtime environment.
Can be the source of subtle bugs, because evaluation at RunTime may have different behaviour and scoping than at CompileTime.
- Any observable difference in the behavior and scoping of eval'd code between CompileTime and RunTime is simply a bug (especially for systems like Smalltalk where "CompileTime" and "RunTime" are identical).
  - It's worth remembering that the vast majority of 'bugs', be they subtle or obvious, aren't caused by a faulty language implementation. If you construct the object-to-be-evaluated at one place and pass it forward to be evaluated someplace else, you can easily end up with behavior you weren't expecting. Further, even if your code is working initially, if someone comes by and adds or removes a variable or changes its name in one of the scoping layers, you may easily end up accessing a variable you weren't expecting to access (or lacking a variable you were expecting).

Maybe it's just me, but it seems most (not all) people who ask for "an eval function" in a language are ScriptKiddies?. They often don't even have a notion of basic features such as closures and scoping rules. Related question: do you need/want dynamic scoping for using an eval() function? WouterLievens?