5 ms·

Co-author of the thesis here - if anybody is interested in the source code, let me know. Keep in mind that JS has changed quite a bit in the years that have pa

Co-author of the thesis here - if anybody is interested in the source code, let me know. Keep in mind that JS has changed quite a bit in the years that have passed and that certain aspects ('eval' in particular) was excluded from the project. Though, it may be an interesting starting point for anybody, who wants to play around with compiling JS.

chrisseaton 7y ago
> 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 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 ago
    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.
    - lispm 7y ago
      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.
    - coldtea 7y ago
      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.
    - justbaker 7y ago
      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 7y ago
  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.

chrisseaton 7y ago

> 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 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 ago
  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.
  - lispm 7y ago
    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.
  - coldtea 7y ago
    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.
  - justbaker 7y ago
    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 7y ago
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.