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?

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

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/

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

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

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

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