Hello Yigal,
I was meaning static as in "static if". I agree with what you've written here. I think my point in this sub-thread is a bit side-tracked from the main topic.
there seems to be a lot of that in this thread
again, what you said is correct, but since in our example we are discussing compile-time as part of run-time, that means there's no difference between static if and regular if (both are executed at run-time).
But one is interpreted and the other manifests as machine code, one can happen before the types of variable are resolved the other after, one only evaluates once during the runtime-compiletime and the other runs every time the function is actually called. Seems like a big enough difference to me.
therefore, you can simplify code by re-factoring it to be regular run-time instead of complicated compile-time that is compiled at run-time. you gain nothing by using compile-time techniques here.
Bare in mind that I'm a compile time techniques junky but I think there is a LOT to be gained (if not in what can be done, it's already Turing compleat after all, then in how and how fast things can be done)
in other words, if I'm generating code at *run-time*, there's no point in providing a *compile-time* trivial shell as you mention above.
I see what your saying, but based on that you can ague that given a pre compile time code generator (lex/yacc?) compile time code generation (Boost::spirit, my dparse or templates in general) is pointless. Using compile time stuff in runtime generated code could be handy where it makes the generation of the code simpler (think swaths of boilerplate)
I think my main point was to answer Andrei's post - that an eval() function in a compiled language is possible and that nothing about a compiled language implies that we shouldn't be able to have this.
My point is that there is no reason that having eval should make a difference in how opDotExp works because there is something akin to a compile time between text and evaluation anyway.
