Fully dynamic d by opDotExp overloading

[Yigal Chripun]

On 19/04/2009 23:33, BCS wrote:
> Hello Yigal,
>
>> On 19/04/2009 01:22, BCS wrote:
>>
>>> Hello Yigal,
>>>
>>>> On 18/04/2009 21:16, Andrei Alexandrescu wrote:
>>>>
>>>>> In the syntax
>>>>>
>>>>> a.b
>>>>>
>>>>> how would either of a and b be identified at runtime? I mean, you
>>>>> write the code somewhere and it gets compiled. It's not like you're
>>>>> reading "a.b" from the console and then call some eval() function
>>>>> against them.
>>>>>
>>>>> Andrei
>>>>>
>>>> what prevents D from having an eval function?
>>>> suppose someone modifies the DMD front-end to compile a string with
>>>> the
>>>> source code of a function in-memory, than this is processed by
>>>> something
>>>> based on DDL and what you get is an API call that takes source code
>>>> in
>>>> a
>>>> string and returns a function pointer.
>>> Even then it is *still* going to be compile time. Just a compile time
>>> running at runtime... Ooohh, my heads's going to start hearing here
>>> in a bit.
>>>
>> No it won't. you will call a standard library API at *runtime* with a
>> *runtime* string and get back a pointer to a function that you can
>> call.
>
> That is exactly what I was thinking of and something I have wanted for
> some time.
>
> But for that to work you need to *compile* the string to a function so
> there is still a compile time inside that function call. That library
> function you refer to, for the topic at hand, is no different than DMD
> and the normal compile process.
>
> To give a concrete example: suppose the eval function was done by
> copying the string to a file, tacking in includes as needed, shelling
> out to DMD to make a DLL/SO and then loading that file back into the
> same process. In that case there would could be a compile time
> resolution. In what way would puling the whole thing inside the first
> process be different?
>
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.

>> in fact Some Lisp compilers implement eval() exactly like that.
>
> The only way I can see that making a difference is if you want that eval
> function to be able to take code that calls function that don't exist
> yet and I don't even want to think about what it would take to implement
> that.
>
>> you're thinking in C++ terms. try thinking in Lisp...
>
> (BTW I may have done more Lisp/schema than C++, saying more about by C++
> history than anything else.)
>
>