<mark_weaver>civodul: I think the answer will probably involve supporting phases in our macro expander, as described in section 7.2 of the R6RS, but I'm not entirely sure that will be enough.
<mark_weaver>specifically, I think we need to support _visiting_ a module before _instantiating_ it. right now, when we compile a module, we generate just one piece of code that does both of these things at the same time, iirc. we need to separate them.
<mark_weaver>actually, I think the requirements are slightly weaker than that.
<mark_weaver>I think we can have circular dependencies, as long as none of the modules in a strongly-connected component (SCC) need any bindings from any other modules in the same SCC at module load time.
<mark_weaver>bindings referenced from thunked fields such as 'inputs' are not needed at module load time.
<mark_weaver>so the problem areas are when a dependency involves macros or referenced from unthunked fields.
<mark_weaver>and we need to make sure that when there is such a load-time (or expand-time) dependency A->B, that A and B are never in the same SCC in the use-module graph.
<mark_weaver>since the vast majority of our cross-module dependencies in gnu/packages/ are referenced only from thunked fields, this gives us considerably more latitude.
<mark_weaver>the cycle detection script shows the SCCs, but doesn't yet highlight the edges within them that are part of the load-deps-graph. that would be a nice addition, although it might be hard to implement properly.
<mark_weaver>with such a feature, you could disregard any SCC that doesn't contain such an edge, and if such an edge was present you could try to remove just that edge.