Re:Compiling Dynamic Languages (2013) [pdf]
by chrisseaton on Sunday April 14, 2019 @09:23AM
(#19659269)
Yeah 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.
Re:Compiling Dynamic Languages (2013) [pdf]
by coldtea on Sunday April 14, 2019 @10:41AM
(#19659659)
Because 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.
One 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.
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.