Fully dynamic d by opDotExp overloading

[Yigal Chripun]

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.