[chrisseaton]

> certain aspects ('eval' in particular) was excluded from the project

If you’re interested in what it takes to compile dynamic languages, why did you leave out such a notable dynamic language feature?

[avidmoon]

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]

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.

[coldtea]

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.

[lispm]

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.

[justbaker]

I 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.

[coldtea]

Because most of the use of dynamic languages doesn't involve eval -- and when it does it's usually considered an anti-pattern.

I doubt you'd find much use of eval in the top 100 most popular Python projects for example.

So it's not exactly that defining a feature.