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


Reply via email to