How about a 100% CTFE?

[Gor Gyolchanyan]

> CTFE must be limited to functions with no side effect, or with side effect that are known and manageable.

A D front-end can be library-based and completely CTFE-able. This
brings a huge set of things you can do with such a front-end.
You can create a full-fledged library-based D compiler if necessary.

On Mon, Nov 7, 2011 at 5:35 PM, Gor Gyolchanyan
<gor.f.gyolchanyan at gmail.com> wrote:
> Can you show an example of when CTFE modifies the state of the program
> and when it's impossible to perform at run-time, provided, that it's a
> separate compiler-aware run-time.
>
>> CTFE must be limited to functions with no side effect, or with side effect that are known and manageable.
>
> Why? There are tons of applications for CTFE other, then initializing variables.
>
> On Mon, Nov 7, 2011 at 5:25 PM, deadalnix <deadalnix at gmail.com> wrote:
>> This doesn't make any sens.
>>
>> Function can modify the state of the program in a non repeatable way, thus
>> compile time function execution isn't possible for thoses.
>>
>> CTFE must be limited to functions with no side effect, or with side effect
>> that are known and manageable.
>>
>> Le 07/11/2011 14:13, Gor Gyolchanyan a écrit :
>>>
>>> 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.
>>
>>
>