cycle dependencies

[DigitalDesigns]

On Wednesday, 30 May 2018 at 18:49:40 UTC, Steven Schveighoffer 
wrote:
> On 5/30/18 11:50 AM, Stefan wrote:
>> On Wednesday, 30 May 2018 at 13:26:53 UTC, Steven 
>> Schveighoffer wrote:
>>> On 5/30/18 8:09 AM, DigitalDesigns wrote:
>>> ... it's really really hard to make it check real 
>>> dependencies.
>> 
>> 
>> For serious dependency checking, you could try 
>> https://github.com/funkwerk/depend.
>> It's used in quite large commercial projects.
>
> OK, so a couple things:
>
> 1. The cycle checking has to be really really fast, and run in 
> a small amount of memory. It runs on startup of EVERY D 
> program. I would LOVE to get rid of this problem, but unless we 
> either invent our own object/linker system, or create some 
> tools to work on the linked binary, we have to do this.
>
> 2. The cycle algorithm is fast and works correctly, given the 
> dependencies that the compiler has provided. It's really not 
> the cycle algorithm that is the problem, but the determination 
> of dependencies. In other words, the problem is the compiler 
> not tracing all the actual dependencies and outlining that in 
> some structure to be parsed later during program startup.
>
> As you increase the number of dependency points, and therefore 
> the graph size, the cycle algorithm has to take longer to 
> figure out if there are any cycles. So even if we can fix the 
> problem outlined here, the cost may not make it worth the 
> effort!
>
> There are some ideas Martin and I have fleshed out a bit, which 
> would help reduced the cyclic dependencies, but so far, nobody 
> has had the time and/or skills to implement. For instance:
>
> https://issues.dlang.org/show_bug.cgi?id=16265
> https://github.com/dlang/druntime/pull/1602#issuecomment-231527759
>
> -Steve

Why is this a runtime issue? It is not as if the execution of 
static this are non-deterministic. The compiler and linker must 
order the calls in some way. Maybe this is what you mean by own 
object/linker?  But even then, they would only have to be checked 
once so why check every time the exe is ran when once it is ran 
it must remain statically oriented for all future.

two exe's could be produced, one with only the static this code 
which is ran after linking and verified, if doesn't pass then a 
linker error is thrown.

These methods could be used for better alternatives but the real 
issue is dependencies of static constructors.

How bout instead require the user to deal with it? The user can 
specify the order to run and the compiler just blindly obeys.

pragma(cycle, 1)
static this()
{

}


...

pragma(cycle, 2)
static this()
{

}

It could require cycle to be unique or just share and let the 
compiler do what it wants(assumes no cycles).

This gives the programmer a fix but doesn't assume there are 
cycles, which most times there are not.

Later on, more intelligent cycle detecting code can be created 
and added and then can give a warning in which the user can go 
back and add the pragmas.

Alternatively, only require the pragmas on modules that 
cyclically import each other. Even if their is no cycle, the 
programmer just adds a pragma to satisfy the compiler/linker/rt.