D and the world

[Alix Pexton]

Mike Parker wrote:
> Alix Pexton wrote:
> 
>> I admit that I did not make this point at all well in my previous 
>> post. I wasn't trying to suggest DSL-to-D translation, if that is what 
>> you mean by "source-to-source", only that in D you have the option to 
>> use the same code at run-time and compile-time, so, if in implementing 
>> an engine that needs to be able to load logic dynamically during 
>> development, you can with careful implementaion, use the same code to 
>> import and compile those same scripts into the executeable when making 
>> a release build.
>>
> 
> Then that defeats the purpose, doesn't it? The idea of scripting is to 
> avoid recompiling the host application. This is especially important to 
> allow modding by users. The goal is for your target scripters, be it the 
> development team or the players, to be able fire up a text editor, make 
> changes to the script, and see them immediately in the game. Requiring 
> CTFE of scripts doesn't make sense in that case.

Thats not what I said. I'm obviously not getting my self accross. While your scripts
are at the design stage, you can load them dynamically and run them as interpretted
code, so you don't have to compile them. When you release your product, you can have
those scripts precompiled as part of the build process. The interpretter is still a
part of the program, and the modders can run there scripts on it just like the
developers did, and if they have access to a D compiler, and the meta-compiler code
(which the developer will of course be free to distribute as with any tool they
create,) then they can compile the script themselves to make a lib (or whatever) that
can then be run natively.

The point that I am trying to get over is not that D can pre compile a DSL and that is
better than interpretting it, but that if the code is written with a few constraints
in mind, then you can have the advantages of both systems, and only have to maintain
one code base.

A...