module dependency circle about cubical HOT 8 CLOSED

I should probably ask this as a general agda question. But in particular I'd like to know what's the practice for this project?

from cubical.

I don't think there is a fixed practice yet. I'm currently trying to arrange results in the most logical way possible, but it is not always so easy. I'm for example not too happy about the current organization of results about equivalences.

from cubical.

I have a solution that's not too elegant: instead of a A.agda B.agda, have several files A1.agda A2.agda B1.agda B2.agda that will solve the dependency circle. In the end, have A.agda B.agda that re-export them.

from cubical.

I think the solution will be very context dependent, if you are running into dependency circles, I would argue you aren't using a logical layout. I can't say much for A's and B's but as mortberg said about equivalences, usually there is a better way to organise.

from cubical.

I think what is needed is to carefully go over the proofs about hlevels and equivalences and figure out the logical dependencies, most likely by reproving some results in order to linearize the dependency tree. I'll try to do this some day because right now many results are scattered throughout the library.

from cubical.

For the sake of reference, #100 is solving (partially) this issue.

from cubical.

In dependent type your definitions are checked sequentially anyway, how can your modules to be cyclic?

from cubical.

The .Base vs .Properties split is now there to minimize dependency cycles, in general the solution will be to split modules in a similar way, unless a bigger reorganization is appropriate.

If you end up inlining proofs be mindful that some definitions are there to avoid creating normal forms that are too big.

from cubical.