Hi, at least in .Net case there is no interpretation going on. All code is JITted, the bytecodes are only used as file representation.
-- Paulo "Peter Alexander" <[email protected]> wrote in message news:[email protected]... > CTFE isn't really an interpreter in the traditional sense. I believe it > just uses the parsed source in its IR form, which is different from normal > byte code interpreters (and also slower). I'm guessing here though, so I > could be wrong. > > Whether I'm right or wrong though, I don't see much use for this. As you > said: > > - CTFE is limited. > - You'd need nearly the whole D compiler, as well as the standard library > and runtime. > - It would be slower than other scripting languages (unless given lots of > attention). > - D wasn't made to be a scripting language. > > The most important thing is simply that CTFE is a function evaluator. For > scripting, that's pretty much useless. You need an entire virtual machine > that you can call into, one that has state and can bind into your main > application. > > I think this would be a lot of work for little gain. >
