eval() (Was: One more update on d-programming-language.org)

[dennis luehring]

Am 17.09.2010 09:51, schrieb Nick Sabalausky:
>>>  One thing that could be used for that is the eval() function I've
>>>  recently
>>>  added to my SemiTwist D Tools library:
>>>
>>>  http://www.dsource.org/projects/semitwist/browser/trunk/src/semitwist/util/process.d
>>>
>>>  Example:
>>>  -----------------------------
>>>  import semitwist.util.all;
>>>  void main()
>>>  {
>>>       auto x = eval!int(q{ return 21 * 2; }); // String can be
>>>  runtime-generated
>>>       assert(x == 42);
>>>
>>>       eval!void( q{ writeln("Hello World"); }, q{ import std.stdio; } );
>>>  }
>>>  -----------------------------
>>
>>  is that something like an "runtime" mixin
>>
>>  would be great to have something like that in the standard - then i can
>>  stop writing my own script interpreter for my at runtime loaded DSLs :-)
>>
>>  (and my dream is that walter can use something like that internaly for
>>  CTFEs)
>
> Yea, that was kind of my original motivation for it. I was really jealous of
> Nemerle's approach to compile-time execution (AIUI, the Nemerle compiler
> just invokes itself to compile the compile-time code, and then loads the
> resulting DLL and runs it).

yea the easiest approach - do you got a link to an good nemerle example 
of this

>I figured there was nothing stopping a
> native-compiled langauge from doing essentially the same. To me,

and without the need for generating a DLL (could be an option)

(but i hope D will get its own "dynamic module" as an abstraction over 
Windows .DLL or Linux .SO that can be maybe used)

 > that
> sounded like "compile-time eval()", so it seemed to make sence to start with
> a run-time eval() (already done, more or less, and potentially useful in
> it's own right) and then toss in whatever compiler hacks/intrinsics would be
> needed to make a ctfe-version possible (still "todo").

a ctf-version of eval or using this idea as an evaluation base (combined 
with an AST which is able to give D informations like pure, static, 
const ...) so there no extra ctfe "intepreter" needed (which can't sadly 
not evolve at the speed the language do)