2 ms·
Because it is not really possible to "compile" an eval expression in the general case. By definition, in a compiler, translation from symbols to code happens o
by avidmoon 7y ago
Because it is not really possible to "compile" an eval expression in the general case.
By definition, in a compiler, translation from symbols to code happens on the beforehand. But eval needs to do this at runtime. This means that to compile a program a la "eval(input_string)" the output program whould need to contain the entire compiler, which gets used to convert the eval_input before running.
So in practice you strapped a kind of interpreter to the output program. This is often inefficient and hackish, and thus it is more desirable to just not have a eval feature.
- chrisseaton 7y agoYeah I get it's problematic. But if you're going to start cutting out the dynamic features, and those you don't think aren't desirable, then why are you challenging yourself to write a compiler language for a dynamic language in the first place? You could cut out all these troublesome features if you just picked a static language.
- lispm 7y agoOne of the reasons is that a class of deployed programs might not need EVAL at all or that it is also not allowed to have EVAL for some reasons.
- coldtea 7y agoBecause you don't need eval to do hugely interesting things in dynamic languages. Heck, you don't even particularly need reflection, but eval even less so.
- justbaker 7y agoI don't think using eval is the main problem he's trying to solve. Eval isn't really a good example of "dynamic programming done right". You don't even need eval to metaprogram in JS.