Whichever VHLL does this will lack eval, which will make it distinctly less HL...
There are ways around this. First, some of the things we currently do in Perl via eval can be done in other ways. *Almost* anything you can do with the block form of eval could be done another way; Perl6 is adding some features in this regard. The string form of eval of course can do some things that would break this, so a solution is still needed for eval. There are a couple of options, and a hybrid approach that I would personally favour. The first approach is to provide an optimizing compiler for a subset of the language that does not provide the string form of eval. Thus, any program that doesn't use that could be compiled. The second approach is to compile all the rest of the code in the usual way but *also* then bundle an interpreter or JIT compiler, so that string eval and things like it would be possible. The hybrid approach is to only bundle the compiler or interpreter if the code being compiled uses the string eval.
I favor the hybrid approach, but really I don't think this is a big deal. The real problem is convincing anyone (well, anyone capable of doing anything about it) that political reasons and the views of C/C++ programmers are good reasons to write _and maintain_ an optimizing compiler despite that for almost the entire existing userbase the existing vm-based solution is the way to go.
In reply to Re: On Scripting versus Compiled solutions
by jonadab
in thread On Scripting versus Compiled solutions
by clintp
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |