"dennis luehring" <dl.so...@gmx.net> wrote in message news:i6uv32$1ij...@digitalmars.com... > On 15.09.2010 22:19, Nick Sabalausky wrote: >> "Philippe Sigaud"<philippe.sig...@gmail.com> wrote in message >> news:mailman.214.1284496545.858.digitalmar...@puremagic.com... >>> On Tue, Sep 14, 2010 at 17:01, Andrei Alexandrescu< >>> seewebsiteforem...@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").