How about a 100% CTFE?

[Gor Gyolchanyan]

Agreed. The drawbacks must be studies completely. That's why I
appreciate all your criticism :-)
About inconsistency. True, this is a bit confusing from one
perspective. But i think we can define a straight-forward way of doing
this.
Here's what I'm thinking about. We currently have two stages of compilation:
* translate to object files
* link into executable files

I suggest separating compile-time preparation into third stage, that
would look like this:
* translate into "run-time code"
* translate into object files
* link into executable files

With this scenario, the compiler will run the first stage on ALL files
first, which will reflect the changes in all files. Then, the run-time
code could be arbitrarily compiled and linked as it's done ATM.
The key feature is, that when you compile your code (even if you do it
with separate compile passes), you always run the CTFE for all files
before you do anything else.
And the exact logic of CTFE can be defined in a single consistent
manner. If the import tree implies a certain dependencies, then the
order of evaluation will honor it, otherwise it will rearrange at
will.
After all, if you increment a compile-time value and you don't specify
any relationship with other files, you must either make it private
(don't provide a public incrementing) or be ready to get arbitrarily
incremented value.

On Tue, Nov 8, 2011 at 6:56 PM, deadalnix <deadalnix at gmail.com> wrote:
> Le 08/11/2011 14:54, Gor Gyolchanyan a écrit :
>>>
>>> Which assert will fail ? Does one will fail ? Note that two different
>>> instances of the compiler will compile b and c, and they are exscluded of
>>> one another import tree so each instance isn't aware of the other.
>>
>> Both will succeed and on both cases a will be 1 because both run
>> independently. It's similar to asking if two different runs of the
>> same program, which increment a global variable will see each others'
>> results. The answer is: no.
>>
>
> Ok I seen your point. The problem is that a is a global variable and is
> incremented 2 times. But at the end, it will ends up that it is incremented
> only one time. Maybe 0.
>
> I think this behaviour should be avoided because of the oinconsistency of
> what is happening at compile time and what you get as a result at run time.
> Some limitation should be added to the solution to not end up in thoses kind
> of behaviour IMO.
>
>>> YOU are comming with a solution, YOU have to explain how it solves every
>>> problems. Everything else is flawed logic.
>>
>> Nothing ever solves every problem. That's a very unwise thing to say
>> for someone, who claims to be logical. problems come and go depending
>> on how the features are used. Each problem (or bunches of problems)
>> must be dealt with explicitly (using inductive logic to account for
>> other possible problems). As i said before, if you have problems, i'll
>> help resolve them. If i don't - i'll withdraw my proposal.
>
> Sorry my mistake, I didn't express myself the right way. I should have saud
> how it solve or do not solve every problems. Obviously, the solution to
> every problem usually do not exists.
>
> The point is that every problems related to the solution must be considered
> to know if the solution is really solving something usefull and if its
> drawback (problem that are not solved or created by the given solution).
>