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

[Nick Sabalausky]

"dennis luehring" <dl.soluz at gmx.net> wrote in message 
news:i6uv32$1ijo$1 at digitalmars.com...
> On 15.09.2010 22:19, Nick Sabalausky wrote:
>> "Philippe Sigaud"<philippe.sigaud at gmail.com>  wrote in message
>> news:mailman.214.1284496545.858.digitalmars-d at puremagic.com...
>>> On Tue, Sep 14, 2010 at 17:01, Andrei Alexandrescu<
>>> SeeWebsiteForEmail at erdani.org>  wrote:
>>>>
>>>>   I think we'll move forward with that one. I'll start working on the
>>> content. Ideas for good tutorial examples?
>>>>
>>>
>>> Maybe more examples of what's interesting me right now than tutorials, 
>>> but
>>> who knows?
>>>
>>> * executing command-lines instructions from a D program. Theme: file 
>>> I/O,
>>> OS
>>> interaction.
>>> An interesting example is having a script that loads a D file, modifies
>>> its
>>> source, asks for DMD to compile it and then runs it and get its result. 
>>> It
>>> could be the first brick to get a REPL / idmd (interactive dmd). Maybe
>>> more
>>> a [challenge] subject than a tutorial example?
>>>
>>
>> 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). I figured there was nothing stopping a 
native-compiled langauge from doing essentially the same. To me, 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").