CTFE - compiling other languages inside D

[Nick Sabalausky]

"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:

string include_C(string filename)
{
    auto cache = filename~".cache";
    if(exists(cache) && timestamp(cache) >= timestamp(filename))
        return loadFile(cache);
    else
    {
        auto result = convert_C(loadFile(filename));
        saveFile(cache, result);
        return result;
    }
}

string convert_C(string src)
{
    // Do the conversion, possibly even by invoking a pre-compiled tool.
}

// Only gets processed if stdio.h has changed
mixin( include_C_file("stdio.h") );

The other big benefit, of course, if that we'd finally get compile-time 
write*() for free.

This would also open the door for a CTFE/library-based buildsystem that 
doesn't require a dedicated "makefile" or equivalent, which is an 
interesting prospect.