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... | [reply] |
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.
| [reply] |
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.
| [reply] |
