How about a 100% CTFE?

Gor Gyolchanyan gor.f.gyolchanyan at gmail.com
Tue Nov 8 05:54:35 PST 2011


> 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.

> Well that my whole point. You are not aware of the problem on the topic you try to solve. You are not qualified for the job. I have no responsability on educating you.

I'm well-aware of what I'm dealing with. What I'm not aware of is the
list of things you don't understand in my proposals (which I'm
currently resolving). You don't understand how _this_ feature would
work with _that_ feature without conflicting and I explain how
(proposing one or more way to do it). If your misunderstandings are
not over yet, it's not reasonable to assume, that my explanations
won't follow them. If, however, i fail to explain something, I'll
withdraw my proposal and restore it if and when i find an answer.

> 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.
On Tue, Nov 8, 2011 at 5:44 PM, deadalnix <deadalnix at gmail.com> wrote:
> Le 08/11/2011 14:31, Gor Gyolchanyan a écrit :
>>>
>>> Well except that module can modify a and not be in the tree.
>>
>> A single compilation includes only two parts: compiling D source code
>> and linking in object files or static libraries. object files and
>> static libraries are by no means involved in compile-time activity,
>> which leaves us with with compiling D source code. A single
>> compilation of D source code can be viewed as a list of import trees,
>> originating from the enlisted modules to be compiled. After
>> eliminating duplicates we have a list of small trees, which can be
>> rooted together to form a single tree, which in turn can be processed
>> as described above. Optionally, in order to allow separate
>> compilations, a cache can be maintained to hold the results of
>> previous compile-time computations to be used in the next ones inside
>> a "project" (to be defined).
>>
>
> module a;
>
> int a = 0;
>
> -------------------
>
> module b;
>
> import a;
>
> int somefunction() {
>        return ++a;
> }
>
> static assert(somefunction() = 1);
>
> -------------------
>
> module c;
>
> import a;
>
> int somefunction() {
>        return ++a;
> }
>
> static assert(somefunction() = 1);
>
> 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.
>
>>> If you have hard time to figure out what the problems are, it is unlikely
>>> that you come up with a satisfying solution, except by being lucky.
>>
>> When i say, i don't see problems, that means, that you didn't present
>> me a problem, which i could not resolve. You point to a problem, i
>> resolve it and vice verse until one of us fails. This is called a
>> discussion.
>>
>
> Well that my whole point. You are not aware of the problem on the topic you
> try to solve. You are not qualified for the job. I have no responsability on
> educating you.
>
> YOU are comming with a solution, YOU have to explain how it solves every
> problems. Everything else is flawed logic.
>


More information about the Digitalmars-d mailing list