How about a 100% CTFE?

[Martin Nowak]

On Mon, 07 Nov 2011 17:49:30 +0100, Don <nospam at nospam.com> wrote:

> On 07.11.2011 14:13, Gor Gyolchanyan wrote:
>> After reading
>>
>>      http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
>>      https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c
>>
>> I had a thought:
>> Why not compile and run CTFE code in a separate executable, write it's
>> output into a file, read that file and include it's contents into the
>> object file being compiled?
>> This would cover 100% of D in CTFE, including external function calls
>> and classes;
>> String mixins would simply repeat the process of compiling and running
>> an extra temporary executable.
>>
>> This would open up immense opportunities for such things as
>> library-based build systems and tons of unprecedented stuff, that I
>> can't imagine ATM.
>
> First comment: classes and exceptions now work in dmd git. The remaining  
> limitations on CTFE are intentional.
>
> With what you propose:
> Cross compilation is a _big_ problem. It is not always true that the  
> source CPU is the same as the target CPU. The most trivial example,  
> which applies already for DMD 64bit, is size_t.sizeof. Conditional  
> compilation can magnify these differences. Different CPUs don't just  
> need different backend code generation; they may be quite different in  
> the semantic pass. I'm not sure that this is solvable.
>
> version(ARM)
> {
>     immutable X = armSpecificCode(); // you want to run this on an X86???
> }
>

I've always thought that it would be worthwhile to experiment with LLVM's  
JIT engine here.
But as has been said quite some care will be necessary for cross  
compilation.
Allowing arbitrary non-pure functions would cause lots troubles.