CTFE - compiling other languages inside D

[Marco Leise]

With the recent ORM and RegEx projects dissecting SQL statements and  
regular expressions turning them into D code, I am impressed by the  
possibilities of CTFE. Where are the limitations to this system? An  
unlikely example would be a C compiler within CTFE that takes a string of  
C source code and turns it into a D mixin. Is that possible?
I have written a visualizer that is supposed to work on the web and as a  
stand-alone application. So I chose JavaScript to implement it, since it  
is the only programming language available to web developers across  
platforms. Then I used Rhino JavaScript for Java, implemented a few web  
APIs in Java (HTML canvas, AJAX) and had an applet for IE8 and older and a  
standalone-application in one go. Rhino compiles JavaScript into Java  
code, but from the untyped nature of JavaScript it is not possible to  
optimize much there and it came down to writing a JavaScript to Java byte  
code compiler for the authors of Rhino. So they cannot use the possibly  
advanced optimization features of the actual Java compiler.
Now there is V8, the JavaScript engine in Chrome which is written in C++,  
uses JIT compilation and profiling and is *very* fast. But if I wanted to  
use D and speed was my only concern I would sacrifice some of the  
ECMAScript standard:
- everything is typed
- code cannot be altered or generated on runtime (i.e. eval)
Some things may be difficult to do. In the following case the "obj" adds a  
new field later on, so the for loop has to iterate over the first two  
fields of that data type, excluding 'newField'.

var obj = { a : 1, b : "text" };
for (var key in obj) {
	...
}
obj.newField = 0.5;

Another tricky case where there have to be two versions of foo for "a" and  
"b" or a common type for "a" and "b" that includes a numeric field "n" and  
a text field "c". That means "a" and "b" would become objects of the same  
type where the compiler would have to check if this is at all possible.

function foo(x) {
	...
}
a = { n : 1 };
b = { c : 'w' };
foo(a);
foo(b);

At the end of the day it wouldn't be 100% ECMAScript any more, but it  
would allow that code to compile in an optimized way and at the same time  
run within a browser. Any standard ECMA feature that doesn't work would  
result in an error message. This would probably also allow browsers to  
apply more optimizations on the resulting code in terms of JIT  
compilation. Here is a small snippet in JavaScript and in D:

function log(x) {
	...
}

var x = 3;
x *= 1.2345;
arr = new Array(10);
for (var i = 0; i < 10; ++i) arr[i] = i;
log(arr[5]);

---------------

function log(long x) {	// we need an 'long' version of the log function
	...
}

double x = 3;	// x is later assigned a floating point number
x *= 1.2345;
long[10] arr;	// the slots in this array are all assigned integral numbers  
before any of them are read
for (int i = 0; i < 10; ++i) arr[i] = i;
log(arr[5]);