www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What does D define for circular dependencies

reply "Mehrdad" <wfunction hotmail.com> writes:
I realize this scenario might look stupid, but I hope the 
underlying problem isn't.

Does D define what happens in a situation like this?


module a;
import b;
static if (!is(typeof(.b.foo))) int foo = 1;


module b;
import a;
static if (!is(typeof(.a.foo))) int foo = 2;
Jun 26 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jun 26, 2012 at 07:27:00PM +0200, Mehrdad wrote:
 I realize this scenario might look stupid, but I hope the underlying
 problem isn't.
 
 Does D define what happens in a situation like this?
 
 
 module a;
 import b;
 static if (!is(typeof(.b.foo))) int foo = 1;
 
 
 module b;
 import a;
 static if (!is(typeof(.a.foo))) int foo = 2;

IIRC, according to TDPL, this is a compile-time error. T -- If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen
Jun 26 2012
prev sibling next sibling parent "Roman D. Boiko" <rb d-coding.com> writes:
On Tuesday, 26 June 2012 at 17:27:01 UTC, Mehrdad wrote:
 I realize this scenario might look stupid, but I hope the 
 underlying problem isn't.

 Does D define what happens in a situation like this?


 module a;
 import b;
 static if (!is(typeof(.b.foo))) int foo = 1;


 module b;
 import a;
 static if (!is(typeof(.a.foo))) int foo = 2;

Yes, TDPL describes similar cases in detail, and I'm sure that D specification does, too. Compilation should fail.
Jun 26 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 26 Jun 2012 13:27:00 -0400, Mehrdad <wfunction hotmail.com> wrote:

 I realize this scenario might look stupid, but I hope the underlying  
 problem isn't.

 Does D define what happens in a situation like this?


 module a;
 import b;
 static if (!is(typeof(.b.foo))) int foo = 1;


 module b;
 import a;
 static if (!is(typeof(.a.foo))) int foo = 2;

I don't think it can. D does runtime circular dependency checking at a very coarse level, but this is forcing static checking. I think the compiler will throw a forward reference/recursion error in this case (and if it doesn't, it should). -Steve
Jun 26 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/26/2012 07:27 PM, Mehrdad wrote:
 I realize this scenario might look stupid, but I hope the underlying
 problem isn't.

 Does D define what happens in a situation like this?


 module a;
 import b;
 static if (!is(typeof(.b.foo))) int foo = 1;


 module b;
 import a;
 static if (!is(typeof(.a.foo))) int foo = 2;

I have brought up similar examples in the past. Compilation should fail. There is no specification on what is legal code and what is not yet. (the obvious answer 'code is illegal if it is contradictory or ambiguous' makes compilation undecidable.) A way to solve the issue is to keep record of what symbol lookups failed in what scopes and to issue an error if a symbol is introduced that was previously decided to not exist. Symbol lookup proceeds as repeated fixed point iteration, where at the end of an iteration, some symbols that are still unresolved are decided to not exist. Simple heuristics can be applied to guide analysis in a way that is as precise as possible. (Eg. analyze what kind of symbols can be introduced by which declarations and always focus symbol resolution on the top connected component of the potential-lookup-dependency graph.) Special care has to be taken for overloads of the same symbol name: int foo(double x){} static if(is(typeof(foo(1))==int) double foo(int x){}// error Another issue is how to treat stuff like this: struct S{ int somemember1, somemember2; mixin(generateSomeMoreDeclarations!(__traits(allMembers, S)()); } Ideally this would be legal, but it becomes non-trivial quite fast.
Jun 26 2012
prev sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 26 June 2012 at 18:05:38 UTC, Timon Gehr wrote:
 On 06/26/2012 07:27 PM, Mehrdad wrote:
 I realize this scenario might look stupid, but I hope the 
 underlying
 problem isn't.

 Does D define what happens in a situation like this?


 module a;
 import b;
 static if (!is(typeof(.b.foo))) int foo = 1;


 module b;
 import a;
 static if (!is(typeof(.a.foo))) int foo = 2;

I have brought up similar examples in the past. Compilation should fail. There is no specification on what is legal code and what is not yet. (the obvious answer 'code is illegal if it is contradictory or ambiguous' makes compilation undecidable.) A way to solve the issue is to keep record of what symbol lookups failed in what scopes and to issue an error if a symbol is introduced that was previously decided to not exist. Symbol lookup proceeds as repeated fixed point iteration, where at the end of an iteration, some symbols that are still unresolved are decided to not exist. Simple heuristics can be applied to guide analysis in a way that is as precise as possible. (Eg. analyze what kind of symbols can be introduced by which declarations and always focus symbol resolution on the top connected component of the potential-lookup-dependency graph.) Special care has to be taken for overloads of the same symbol name: int foo(double x){} static if(is(typeof(foo(1))==int) double foo(int x){}// error Another issue is how to treat stuff like this: struct S{ int somemember1, somemember2; mixin(generateSomeMoreDeclarations!(__traits(allMembers, S)()); } Ideally this would be legal, but it becomes non-trivial quite fast.

Cool, that answers it perfectly. Thanks!
Jun 26 2012