On 7/25/11 12:55 PM, bearophile wrote:
(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
That's why I suggest abstracting away the CTFE to the backend. DMD's
backend could implement it as now, just interpreting things in memory
and basically implementing an interpreter from scratch. For LDC the
backend could just JIT-compile the functions and execute them without
any restriction at all...
