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