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)
