Expose the CTFE interpter in Phobos?

bearophile bearophileHUGS at lycos.com
Mon Jul 25 08:53:49 PDT 2011


(This post is related to something I have suggested time ago, to offer some parts of the D compiler through the D standard library itself (to use the compiler at run-time for some purposes), as recent versions of C#-dotnet too do.)

There is a part of the D compiler that to me seems more useful than other ones, I mean the D interpreter used for CTFE. People often add Lua, Python, MiniD, JavaScript to large C/C++/D programs (I think most video games contain some kind of interpreter). So is it possible to offer this part alone to the D programmer? With it you are allowed to create at runtime small strings of D code and interpret it. No need to learn and add a second scripting language to do it. Just import a function execute() from a Phobos module :-)

The (hopefully) introduction of some writing function (http://d.puremagic.com/issues/show_bug.cgi?id=3952  https://github.com/D-Programming-Language/dmd/pull/237 ) will make run-time D interpretation even more useful.

There are disadvantages:
- Even with some printing function, CTFE interpreter is limited. Don will remove some more CTFE limitations like allowing classes and exceptions, but a "scripting language" that can't read and save files is less useful; so maybe it can't fully replace a Lua interpreter.
- If you want to use this feature you need the whole D compiler at run time too. The D compiler is probably much bigger than a Lua interpreter. On the other hand maybe it's possible to push the CTFE interpreter in a DLL that is normally used by the D compiler, that the D standard library uses if you want to interpret D code at run time. I don't know if this DLL is going to be small enough.
- CTFE is currently much slower than dynamic/scripting languages like LuaJIT (that are becoming almost as fast as well compiled D). But in LDC with the LLVM back-end you have all the tools to create a JIT for interpted D code too :-) LLVM is not a compiler, it's an aggregate of parts.
- D language is not as simple as a scripting language. In video games the people that write the 3D engine in C++ are not the same people that program game logic in Lua. The second group of people has different skills, and they often are not good programmers able to write C++ code too. So among other things Lua is used to allow a large number of people to write how the game has to act, not just hard-core C++ programmers.

Do you know/have use cases for running D code (with current or near-future CTFE limitations) at run-time?

Bye,
bearophile


More information about the Digitalmars-d-bugs mailing list