Fully dynamic d by opDotExp overloading

[BCS]

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.

[ot] the annoying thing about this whole thread is that I'd bet a small amount 
of money that I could convince anyone here of my point in about 5 minuets 
if I had me, them and a chalkboard in the same room. I think almost all the 
confusion is not because people would disagree with what I'm trying to say 
but because there are about 5 different and almost unconnected things people 
are arguing about: a sort of "A is true"/"No, B is true" where A != B and 
A != !B and !A != B ...

Written language has the advantage that you can be very precise and thought 
out but has zero real time feedback like you get in a face-to-face and an 
insanely long delay for what feedback it does have.