Fully dynamic d by opDotExp overloading

[BCS]

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?

> 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.)