<div dir="ltr">My experience may not be representative, but I've done waves of updating packages for a <span style="background-color:rgb(245,246,245)">new </span>major GHC release a few times now. I believe for the AMP-containing update of GHC I submitted patches to over 40 packages. My experience is far from universal, but I extensive enough to be informative.<div><br></div><div>In my experience, Haskell's types gave precise sources for the error. As the packages form a DAG, issues with dependency packages were sorted out before I got to packages using them since the types caught any issues at the point that package was compiled. By when the dependent package was compiled, the type signatures of the dependency package was decided, and any compilation issues represented a legitimate API change requiring a patch to the package failing to compile. GHC flagged these issues at the point of use. Only rarely did I have to look in more than one place, and in those cases, it was universally inside the same package. Most of these were caused by changes in the unifier and were from the use of moderately exotic type system extensions that were purposefully changed causing disagreement inside the package about how to resolve the types since the design depended on ambiguity.</div><div><br></div><div>Other than this last case, fixing the packages has been almost entirely procedural. It might take some time and familiarization with the package to make sure the change made was of sufficient quality to warrant submitting a patch instead of merely being correct, but it was never any mystery where the problem lay. I'd be curious what sort of issues you're encountering that caused confusion about the origin point of the issue. Its been over a decade since I used an ML language though so I'm not sure how Ocaml's type level specifications interact across packages. OCaml has some features that seem like they may lead to less orderly resolution of such problems (module functors come to mind as potentially interfering with the orderly nature of package dependencies).</div><div><br></div><div>-davean</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 31, 2018 at 5:32 AM, Sébastien Hinderer <span dir="ltr"><<a href="mailto:Sebastien.Hinderer@inria.fr" target="_blank">Sebastien.Hinderer@inria.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br>
<br>
I am part of the OCaml development team. As you may know, OCaml has a<br>
package manager a bit similar to cabal whose name is opam.<br>
<br>
One of my colleagues spends quite a lot of time trying to make sure that<br>
packages still compile with a new version of the compiler, when we<br>
release it. When a package does not compile any longer, it seems it is a<br>
highly non-trivial task to figure out what exactly is broken: is it the<br>
package itself which has been broken by a change in the compiler, or is<br>
it one of its dependencies.<br>
<br>
I am assuming the same kind of problems occur with Haskell and am<br>
wondering how they are handle.<br>
<br>
Has there been something published on this kind of problem?<br>
<br>
Any pointer, comment or contact appreciated.<br>
<br>
Best wishes,<br>
<br>
Sébastien.<br>
______________________________<wbr>_________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.<wbr>org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/glasgow-<wbr>haskell-users</a><br>
</blockquote></div><br></div>