• bearophile (11/11) Jul 25 2011 (This post is related to something I have suggested time ago, to offer s...
• bearophile (3/3) Jul 25 2011 Please ignore this post, the web interface is now more buggy than it use...

bearophile <bearophileHUGS lycos.com> writes:

(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

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

bearophile <bearophileHUGS lycos.com> writes:

Please ignore this post, the web interface is now more buggy than it used to be.

Sorry,
bearophile