CTFE - compiling other languages inside D

[Timon Gehr]

Nick Sabalausky wrote:
> "Adam D. Ruppe" <destructionator at gmail.com> wrote in message
> news:j1ufc0$avd$1 at digitalmars.com...
>> Marco Leise wrote:
>>> 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?
>>
>> It'd be a fair amount of work, but it should be possible.
>>
>> It's tempting to try to implement that as an alternative to D
>> bindings modules.
>>
>> mixin include_C ( import("stdio.h") );
>>
>
> It's a neat possibility, but the downside of that approach, I suspect, is
> that it may slow down compilation.
>
> With that approach, "stdio.h" has to be processed *every* time your program
> is compiled, not just whenever "stdio.h" is changed (which is what you would
> get if the conversion were done with a separate tool and a proper
> buildsystem). Also, I'm sure that CTFE is probably slower than running an
> already compiled tool. It would have to be slower, since it *is*
> interpreted, after all.
> This is another reason why CTFE really needs to support IO access (I really
> believe the strict adherance to "CTFE must be *guaranteed* stateless" is a
> mistake. It's right to strongly discourage it, but making the ban this
> strict is taking things too far - similar to Java's ban on pointers). Then,
> include_C could be implemented roughly like this:
> [snip.]

Another interesting way to speed up CTFE-heavy code compilation in a incremental
build environment would be to allow the compiler to cache the internal
AST-representation of the code after semantic analysis, in some kind of temporary
file.