Whichever VHLL does this will lack eval, which will make it distinctly less HL...

Not necessarily so. You just need to include your compiler with the binary. Languages like Lisp and Pop-11 have been doing that for years.

Go back to Re: On Scripting versus Compiled solutions and read the following sentence, ...I don't think a bundlemonkey approach (binding the interpreter and the bytecode together into an executable package) will do the trick.

The approach that you suggest (including the compiler with the binary) is exactly the "bundlemonkey" approach that jonadab ruled out. And my claim is that if you rule that out, then you run into problems with eval.

Well..I'm not sure what he would think of Squeak's approach (decompile the running environment into C++ code which, when compiled again, gives you the same environment again). That isn't the usual "bundlemonkey" approach, but it isn't totally dissimilar either...

The approach that you suggest (including the compiler with the binary) is exactly the "bundlemonkey" approach that jonadab ruled out. And my claim is that if you rule that out, then you run into problems with eval.

Actually, tilly, what adrianh is suggesting is not the bundlemonkey approach. There's an important middle ground: include optimized native code, not bytecode, and also include a compiler that generates optimized native code on the fly when necessary. This is significantly different from producing bytecode and a bound interpreter.

On further reflection, including the compiler (which converts source to bytecode or native code) or not and having code as bytecode + interpreter (bundlemonkey) or as native code are really orthogonal choices. Many commercial lisp variants produce output that has the compiler but also uses (mostly) native code, whereas Visual Basic programs take the opposite approach: classic bundlemonkey but without runtime access to the compiler.

The approach that you suggest (including the compiler with the binary) is exactly the "bundlemonkey" approach that jonadab ruled out. And my claim is that if you rule that out, then you run into problems with eval.

I had assumed that jonadab meant that the building-the-interpereter technique wouldn't do the trick because it still wouldn't be a "real" program and you would still suffer from the speed issues that interpreted code would suffer in comparison to optimised native code.

Personally I don't think it would solve the problem in any case. A language bigot of whatever colour will remain a language bigot. Minor things like evidence never seem to change anything.

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.