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 parent reply 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
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