www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Argh!! Cyclic dependencies!!!

reply "Nick Sabalausky" <a a.a> writes:
These module constructor "Cyclic dependencies" errors are really starting to 
piss me off. I feel like I'm back in the days when you'd sneeze and DMD 
would vomit out 100 forward reference errors just because you didn't write 
your whole damn app in one giant ultra-module. (/me takes a breather to 
chill out...Ok...)

I don't suppose there's any chance we could get a quick little:

import foo;

pragma(staticCtorsAvoid, foo);
// Or
pragma(staticCtorsRunBefore, foo);
// Or
pragma(staticCtorsRunAfter, foo);

static this()
{
    // do trivial shit that doesn't touch foo
}

Could we? I don't care which it is. I don't care if it doesn't enforce any 
safety at all. I don't care if it gets depricated in favor of an alternate 
solution in a later version. I just need a way to say "this'll work, dmd, 
just do it and quit yer damn whinin'!!" Doesn't need to be perfect, just 
needs to work. At the very least, if I manage to be able to hack something 
like that it in, would there be any chance of it getting accepted?
Mar 18 2011
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Nick Sabalausky Wrote:


 These module constructor "Cyclic dependencies" errors are really starting to 
 piss me off. I feel like I'm back in the days when you'd sneeze and DMD 
 would vomit out 100 forward reference errors just because you didn't write 
 your whole damn app in one giant ultra-module. (/me takes a breather to 
 chill out...Ok...)
 
 I don't suppose there's any chance we could get a quick little:
 
 import foo;
 
 pragma(staticCtorsAvoid, foo);
 // Or
 pragma(staticCtorsRunBefore, foo);
 // Or
 pragma(staticCtorsRunAfter, foo);
 
 static this()
 {
     // do trivial shit that doesn't touch foo
 }
 


Could module-level globals be treated like local variables to the static
constructor for the purpose of checking purity?

AKA
static this() pure
{
  // trivial stuff
  // calls weakly pure functions
  // writes module-level globals
  // reads module-level globals
  // etc...
}


That's compiler enforceable and effectively means that stati constructor does
not count as part of a cyclic dependency...
Mar 18 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-03-18 19:24:41 -0400, Jason House <jason.james.house gmail.com> said:


 Nick Sabalausky Wrote:
 

 These module constructor "Cyclic dependencies" errors are really starting to
 piss me off. I feel like I'm back in the days when you'd sneeze and DMD
 would vomit out 100 forward reference errors just because you didn't write
 your whole damn app in one giant ultra-module. (/me takes a breather to
 chill out...Ok...)
 
 I don't suppose there's any chance we could get a quick little:
 
 import foo;
 
 pragma(staticCtorsAvoid, foo);
 // Or
 pragma(staticCtorsRunBefore, foo);
 // Or
 pragma(staticCtorsRunAfter, foo);
 
 static this()
 {
 // do trivial shit that doesn't touch foo
 }
 


 
 Could module-level globals be treated like local variables to the 
 static constructor for the purpose of checking purity?
 
 AKA
 static this() pure
 {
   // trivial stuff
   // calls weakly pure functions
   // writes module-level globals
   // reads module-level globals
   // etc...
 }
 
 
 That's compiler enforceable and effectively means that stati 
 constructor does not count as part of a cyclic dependency...


That would work nicely, except for one thing: static constructors can 
be used to build immutable global variables. And pure functions have 
access to immutable global variables. This means two things:

1. purity isn't really guarantied for pure functions inside a module 
constructor
2. pure functions could access immutable global variables of other 
modules before their initialization

I think the pragma is a more viable solution, athough not very elegant.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Mar 18 2011
parent "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:im0s22$2fap$1 digitalmars.com...

 On 2011-03-18 19:24:41 -0400, Jason House <jason.james.house gmail.com> 
 said:


 Nick Sabalausky Wrote:


 These module constructor "Cyclic dependencies" errors are really 
 starting to
 piss me off. I feel like I'm back in the days when you'd sneeze and DMD
 would vomit out 100 forward reference errors just because you didn't 
 write
 your whole damn app in one giant ultra-module. (/me takes a breather to
 chill out...Ok...)

 I don't suppose there's any chance we could get a quick little:

 import foo;

 pragma(staticCtorsAvoid, foo);
 // Or
 pragma(staticCtorsRunBefore, foo);
 // Or
 pragma(staticCtorsRunAfter, foo);

 static this()
 {
 // do trivial shit that doesn't touch foo
 }


 Could module-level globals be treated like local variables to the static 
 constructor for the purpose of checking purity?

 AKA
 static this() pure
 {
   // trivial stuff
   // calls weakly pure functions
   // writes module-level globals
   // reads module-level globals
   // etc...
 }


 That's compiler enforceable and effectively means that stati constructor 
 does not count as part of a cyclic dependency...


 That would work nicely, except for one thing: static constructors can be 
 used to build immutable global variables. And pure functions have access 
 to immutable global variables. This means two things:

 1. purity isn't really guarantied for pure functions inside a module 
 constructor
 2. pure functions could access immutable global variables of other modules 
 before their initialization

 I think the pragma is a more viable solution, athough not very elegant.


Yea, I agree the pragma is inelegant, but I figure a quick-n-dirty stop-gap 
workaround for this is a lot better than waiting for a proper solution.
Mar 18 2011
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 18 Mar 2011 17:42:58 -0400, Nick Sabalausky <a a.a> wrote:


 These module constructor "Cyclic dependencies" errors are really  
 starting to
 piss me off. I feel like I'm back in the days when you'd sneeze and DMD
 would vomit out 100 forward reference errors just because you didn't  
 write
 your whole damn app in one giant ultra-module. (/me takes a breather to
 chill out...Ok...)

 I don't suppose there's any chance we could get a quick little:

 import foo;

 pragma(staticCtorsAvoid, foo);
 // Or
 pragma(staticCtorsRunBefore, foo);
 // Or
 pragma(staticCtorsRunAfter, foo);

 static this()
 {
     // do trivial shit that doesn't touch foo
 }

 Could we? I don't care which it is. I don't care if it doesn't enforce  
 any
 safety at all. I don't care if it gets depricated in favor of an  
 alternate
 solution in a later version. I just need a way to say "this'll work, dmd,
 just do it and quit yer damn whinin'!!" Doesn't need to be perfect, just
 needs to work. At the very least, if I manage to be able to hack  
 something
 like that it in, would there be any chance of it getting accepted?


If you are interested, the code that runs the static ctors is in druntime,  
not the compiler.  So you can turn off the errors if you want in your  
local copy of druntime.

FWIW, there is a "standalone" flag which allows you to skip cycle  
detection on that module.  I'm not quite sure why the compiler sets that  
flag, but it has something to do with little modules created by the  
compiler itself.  When I rewrote the cycle detection code, I used to have  
an idea of why, but it's faded from my memory.

In any case, I think you could do something repulsive like naming your  
module nodeps_x instead of x, and have the cycle detection skip over that  
module when detecting cycles.  Bottom line is, there is no valid static  
data before static ctors run, so you must figure out how to get the info  
to the cycle detection routine without static data.

If we are changing the compiler, I'd like this:

 standalone module foo;

which would tell the compiler to set the standalone flag, no proof  
required.  I don't think it's really possible to verify that a static ctor  
does not depend on outside data without full analysis which isn't  
currently possible.

-Steve
Mar 21 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vso2wwsweav7ka steve-laptop...

 If you are interested, the code that runs the static ctors is in druntime, 
 not the compiler.


Yea, I had a feeling druntime would be involved since the cycles get 
reported at runtime. Thanks for confirming, though.


 In any case, I think you could do something repulsive like naming your 
 module nodeps_x instead of x, and have the cycle detection skip over that 
 module when detecting cycles.  Bottom line is, there is no valid static 
 data before static ctors run, so you must figure out how to get the info 
 to the cycle detection routine without static data.


I'm not very familiar with how druntime works. Are you implying that sending 
information from a pragma to druntime would inherently require using valid 
static data from a static ctor?

I take it that the answer from the-powers-that-be to the question "Is there 
a chance that a stop-gap solution might be accepted?" is "no comment"? If 
there's any worry about a "there's a chance of it" being misinterpreted as a 
promise for inclusion, I can assure that I'm an adult and do know the 
difference between "yes" and "maybe".
Mar 21 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 21 Mar 2011 18:45:23 -0400, Nick Sabalausky <a a.a> wrote:


 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vso2wwsweav7ka steve-laptop...

 If you are interested, the code that runs the static ctors is in  
 druntime,
 not the compiler.


 Yea, I had a feeling druntime would be involved since the cycles get
 reported at runtime. Thanks for confirming, though.


 In any case, I think you could do something repulsive like naming your
 module nodeps_x instead of x, and have the cycle detection skip over  
 that
 module when detecting cycles.  Bottom line is, there is no valid static
 data before static ctors run, so you must figure out how to get the info
 to the cycle detection routine without static data.


 I'm not very familiar with how druntime works. Are you implying that  
 sending
 information from a pragma to druntime would inherently require using  
 valid
 static data from a static ctor?


No, I was saying if you want a stop-gap solution that does not involve  
modifying the compiler, you have to use what the compiler gives you.   
Namely, what is in the ModuleInfo.  You can't rely on something like a  
static initializer.

If you have a pragma, no changes to druntime are necessary, it already has  
the capability of skipping modules marked with the standalone flag.


 I take it that the answer from the-powers-that-be to the question "Is  
 there
 a chance that a stop-gap solution might be accepted?" is "no comment"? If
 there's any worry about a "there's a chance of it" being misinterpreted  
 as a
 promise for inclusion, I can assure that I'm an adult and do know the
 difference between "yes" and "maybe".


I think a pragma or an annotation would be considered by the  
powers-that-be.  No response from Walter is usually a good sign that he's  
not adamantly against it ;)

-Steve
Mar 22 2011