https://issues.dlang.org/show_bug.cgi?id=14666

This bug has become a blocker for SDC. I was able to work around it in various places so far, but this becomes harder and harder to do so.

On 6/9/2015 6:43 PM, deadalnix wrote:
> https://issues.dlang.org/show_bug.cgi?id=14666
>
> This bug has become a blocker for SDC. I was able to work around it in various
> places so far, but this becomes harder and harder to do so.

I suggest as a workaround to restructure the code so it is not doing circular imports.

On Wednesday, 10 June 2015 at 01:43:41 UTC, deadalnix wrote:
> https://issues.dlang.org/show_bug.cgi?id=14666
>
> This bug has become a blocker for SDC. I was able to work around it in various places so far, but this becomes harder and harder to do so.

Good news! This is a regression in D 2.061.

OK, that's not really good news, but regressions do have a higher likelihood of getting fixed.

On Wednesday, 10 June 2015 at 02:01:14 UTC, Walter Bright wrote:
> On 6/9/2015 6:43 PM, deadalnix wrote:
>> https://issues.dlang.org/show_bug.cgi?id=14666
>>
>> This bug has become a blocker for SDC. I was able to work around it in various
>> places so far, but this becomes harder and harder to do so.
>
> I suggest as a workaround to restructure the code so it is not doing circular imports.

The actual code is far more complex than the presented sample :)

That what I'm trying to do in general, but here I'm faced with cases that are very hard to untangle.

Also, I do think this kind of weird edge cases are what give D this immage of immature language (it has gotten much better over the past few years, so there is that).

On 6/9/2015 10:39 PM, deadalnix wrote:
> The actual code is far more complex than the presented sample :)
>
> That what I'm trying to do in general, but here I'm faced with cases that are
> very hard to untangle.

The 'tangle' of cyclical import graphs, as you so appropriately put, is not only hard on the compiler, it makes it much harder for human readers to make sense of code. Even reading your little code snippet hurts my brain.

Go, in one of their better decisions, decided "Thou Shalt Not Have Import Cycles". This forces users to untangle their code, and I believe that is A Good Thing.

I'd like to do that for D, but of course it is far too late for that.

On Wednesday, 10 June 2015 at 06:55:43 UTC, Walter Bright wrote:
> On 6/9/2015 10:39 PM, deadalnix wrote:
>> The actual code is far more complex than the presented sample :)
>>
>> That what I'm trying to do in general, but here I'm faced with cases that are
>> very hard to untangle.
>
> The 'tangle' of cyclical import graphs, as you so appropriately put, is not only hard on the compiler, it makes it much harder for human readers to make sense of code. Even reading your little code snippet hurts my brain.
>
> Go, in one of their better decisions, decided "Thou Shalt Not Have Import Cycles". This forces users to untangle their code, and I believe that is A Good Thing.
>
> I'd like to do that for D, but of course it is far too late for that.

That wouldn't be possible. For the most part, the cases where I have these kind of thing are due to mixin being non hygienic, forcing to import thing I should have been passing via template argument.

A typical example of that in SDC is the way types are handled.

SDC has AST and IR, which share some common feature when it comes to type, but are also different. There is a module that implement the common feature for IR types and AST types.

Problem is, this base uses bitfield from the standard lib, which in turn uses mixin. Meaning I can't use the base with importing all modules where it is going to be instantiated. This in turn cause the forward reference thing and forces me to bypass the type system in various places to avoid it.

This means either make Liskov very sad and create a 'tangle' with imports, or just not use the standard lib and duplicate a ton of code.

2015-06-10 15:55 GMT+09:00 Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com>:

> On 6/9/2015 10:39 PM, deadalnix wrote:
>
>> The actual code is far more complex than the presented sample :)
>>
>> That what I'm trying to do in general, but here I'm faced with cases that
>> are
>> very hard to untangle.
>>
>
> The 'tangle' of cyclical import graphs, as you so appropriately put, is not only hard on the compiler, it makes it much harder for human readers to make sense of code. Even reading your little code snippet hurts my brain.
>
> Go, in one of their better decisions, decided "Thou Shalt Not Have Import Cycles". This forces users to untangle their code, and I believe that is A Good Thing.
>
> I'd like to do that for D, but of course it is far too late for that.
>

D has true forward reference resolution mechanism. In that case modules are cyclic imported, but the declared symbols don't have actual cyclic references. Therefore the snippet should work.

https://github.com/D-Programming-Language/dmd/pull/4735

And the regression was introduced by your unrelated change. While fixing the issue, I couldn't understand why it was necessary.

https://github.com/D-Programming-Language/dmd/commit/a04cf864b932061ad7b72e7cad8b16fabc6a825a

Kenji Hara

I have always been wondering why cyclic imports are allowed in D and if those enable certain design that is not possible otherwise. That mixin case sounds interesting but doesn't "click" :)

On Wednesday, 10 June 2015 at 06:55:43 UTC, Walter Bright wrote:
> On 6/9/2015 10:39 PM, deadalnix wrote:
>> The actual code is far more complex than the presented sample :)
>>
>> That what I'm trying to do in general, but here I'm faced with cases that are
>> very hard to untangle.
>
> The 'tangle' of cyclical import graphs, as you so appropriately put, is not only hard on the compiler, it makes it much harder for human readers to make sense of code. Even reading your little code snippet hurts my brain.
>
> Go, in one of their better decisions, decided "Thou Shalt Not Have Import Cycles". This forces users to untangle their code, and I believe that is A Good Thing.
>
> I'd like to do that for D, but of course it is far too late for that.

Ada (83 and 95) were also rigid about not allowing any kind of import cycles. At some point, probably after Ada 95 when OO was added, it was decided after much experience that there were some cases where it was better to allow it. If you're interested, in the Ada world this issue was dubbed "the with-ing problem" and a quick Google search gives

http://www.ada95.ch/doc/within/FAQ.html#what

http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-4-2.html

also in the world of Haskell, this thread

https://mail.haskell.org/pipermail/haskell-cafe/2004-September/006885.html

and I'm sure in many other places too.

I agree with you, Walter, that mutual recursion amongst imports is usually bad, but I think you inadvertently made the right decision by allowing it in D, and that the bug should be fixed. If people overuse it to write messy code then the community should tell them to write that code better.

On 6/10/15 8:41 AM, Brian Rogoff wrote:
> I agree with you, Walter, that mutual recursion amongst imports is
> usually bad, but I think you inadvertently made the right decision by
> allowing it in D, and that the bug should be fixed. If people overuse it
> to write messy code then the community should tell them to write that
> code better.

I agree. I'm one of those folks who think circular dependencies are fine, thank you very much, and the few cases in which it causes problems should be flagged and diagnosed in a principled way.

Everybody also likes:

* recursion and mutual recursion of any depth (there's a lot more of it going in the usual programs than one might think)

* recursive and mutually recursive types

* declaring top level names in any order and they just "work"

But all of a sudden, people get sugar in their gasoline and sand in their gears when they hear of the same thing applied to modules. I suspect it's because some legacy languages didn't quite do a stellar job at it. Figuring that stuff out and pointing out problems is exactly the kind of thing computers are good at and humans, not so good.


Andrei