On 20/04/2009 01:13, BCS wrote:
Hello Yigal,
everything you said is true. there is some sort of a compile-time
since
the code is getting compiled. But in the above scheme there isn't any
real difference between run-time and compile-time and this distinction
has lost its meaning.
compare the following:
process A:
1) use runtime dispatch based on run-time user input
2) generate source code for the above case "on the fly"
2) compile the above code and call it
process B:
1) generete templated source code at runtime
2) call run-time compiler module on the above code
3) compiler instantiates the template based on the input at
*compile-time* (i.e. compile time dispatch)
4) call the templated instance
the above are identical even if implemented differently since that
compile-time above is actually part of the run-time.
the only difference is the style of coding and I'd argue that the
second
process is unnecessarily more complex without any gains.
if nothing else than the source code generated will be shorter since
you
wouldn't need to stick "static" everywhere.
I think you understand my point about what is possible but I'm not sure
you are spotting what I'm saying regarding what should be done. I'll try
and cleanly state what I'm asserting:
a number of red hearings seem to be floating about based on cool uses
for truly runtime dynamic function lookup (that we just agreed doesn't
exist for the given syntax as for that case, the binding happens at sort
sort of compile time). I'm calling them red herrings because those uses
can be done with other functionalties that already exist.
If we throw those out, the only new functionality remanding that any of
this thread has provided is allowing the following syntax:
a.b(args);
to be used when the type of 'a' doesn't define a 'b'. What a lot of
debate seems to be about is if that should be translated to:
a.opDotExp("b", args);
or
a.opDotExp!("b", typeof(args))(args);
but that's an easy question (go with option 2) if you note that the
transformation is always at /some sort/ of compile time. If you want
this and the non-static (a.k.a. the non compile time binding (where you
thinking of static like static member and not static if/assert?)) form
you can implement the non-static version using existing devices and make
the above a trivial shell around.
Trying to go the other way doesn't work as there is no way to make
static decisions (static if or template specialization) in a purely
runtime mode using runtime values.
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.
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).
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.
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 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.
