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

[Nick Sabalausky]

"dennis luehring" <dl.soluz at gmx.net> wrote in message 
news:i70ibg$1llq$1 at digitalmars.com...
> 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
>

Nemerle does it with their macros:

http://nemerle.org/Macros_tutorial#Compiling_a_simplest_macro

A few things to keep in mind about that:

1. Nemerle macros are functions that run at compile-time and return syntax 
trees which are then "mixed in" automatically.

2. The <[xxx]> syntax basically means (in D-ish psuedo-code): 
(xxx).syntaxTreeOf

3. In Nemerle, like Ruby, putting an expression/value as the last statement 
in a function basically counts as an implicit "return ...;" statement.

4. Apperently I was wrong in my understanding that Nemerle invokes itself 
automatically to compile compile-time code. Apperently *you* have to compile 
it into a DLL first, and *then* you "link" it in (really you "reference" it 
on the command line) when you compile any code that uses it. I like my idea 
better :)

5. Combining <[xxx]> with Nemerle's very, very nice "match" syntax gives 
Nemerle D's fabled "AST macros", and in a more flexible, orthogonal way 
(Nemerle's match is like switch, but match is a Ferarri and switch is a 
Pinto).

I really need to actually download the Nemerle compiler and try this stuff 
out though. I've still never done so yet. So it's possible my 
interpretations of the documentation may be inaccurate.


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

There was the DDL project awhile ago that looked promising. I don't know 
whether it's still around or not, though.


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

Did this get garbled somehow? I don't understand. (But maybe it's just me, I 
barely got any sleep.)