On 03/14/2014 11:50 PM, deadalnix wrote:
> ...
>> "Any attempt to resolve a symbol will create a poison at the
>> corresponding entry. ... Construct of priority 2 are evaluated in
>> order of appearance in the source."
>>
>> Order of appearance in the source is not well-defined. There can be
>> circular imports. In any case, strategies dependent on declaration
>> order at all do not result in predictable/flexible enough semantics in
>> my opinion. One would need to reduce in parallel until analysis is
>> completely stalled on lookups of unpoisoned symbols. Then one poisons
>> all the stalled lookups in the topmost strongly connected component of
>> the lookup-dependency-graph at once.
>>
>
> Order of inclusion only matter for symbol in socpe when compile time
> construct are present. They may introduce random symbols, it do not
> seems possible to make them independent of order in the source code in a
> paradox free manner. I have no proof of this, and I'd be happy to be
> proven wrong.
> ...

It can be done. (What I described above works strictly better than the DIP afaics.)

> You are also right, they is an hole in the proposal when it comes to
> loop in module inclusion. I still think the proposal is a huge
> improvement over the current situation.
>
>> Eg. the following simple cases are easily seen to be completely
>> unambiguous by this strategy:
>>
>> ...
>>
>
> I'm not sure what you think should happen as per my proposal here.

I think per your proposal, those would fail, but I think they should be valid, as they can be processed and proven unambiguous by a reasonably simple and quite general order-independent strategy.

> Both
> module fail at the very first conditional :
> static if(foo){ mixin("enum bar=true;"); } // priority 3, evaluate in
> order, foo doesn't exists. Error.
> mixin(qux); // Same here, qux do not exists, error.
>
>> Unfortunately this is not yet sufficient, eg. the following
>> reasonably-looking case is not shown to be unambiguous by this
>> strategy alone.
>>
>> enum x = "enum xx = q{int y = 0;};";
>>
>> struct SS{
>>     mixin(xx);
>>     mixin(x); // error, xx poisoned
>> }
>
> mixin are priority 2. mixin(xx) is processed first and is an error. If
> an xx string is defined somewhere (for instance in a imported module not
> present in the sample code) then mixin(x) becomes indeed an error, as it
> override the symbol xx, which would change the semantic of the previous
> mixin.

Yup.

On Friday, 14 March 2014 at 23:25:47 UTC, Timon Gehr wrote:
> On 03/14/2014 11:50 PM, deadalnix wrote:
>> ...
>>> "Any attempt to resolve a symbol will create a poison at the
>>> corresponding entry. ... Construct of priority 2 are evaluated in
>>> order of appearance in the source."
>>>
>>> Order of appearance in the source is not well-defined. There can be
>>> circular imports. In any case, strategies dependent on declaration
>>> order at all do not result in predictable/flexible enough semantics in
>>> my opinion. One would need to reduce in parallel until analysis is
>>> completely stalled on lookups of unpoisoned symbols. Then one poisons
>>> all the stalled lookups in the topmost strongly connected component of
>>> the lookup-dependency-graph at once.
>>>
>>
>> Order of inclusion only matter for symbol in socpe when compile time
>> construct are present. They may introduce random symbols, it do not
>> seems possible to make them independent of order in the source code in a
>> paradox free manner. I have no proof of this, and I'd be happy to be
>> proven wrong.
>> ...
>
> It can be done. (What I described above works strictly better than the DIP afaics.)
>

It is difficult to judge, you didn't provided many details. I
don't see how your proposal could work without having significant
risk of heavy backtracking. Can you precise what you have in mind
?