It may be that there’s quite a bit of code that doesn’t have explicit top
level type signatures? That’s legal in Haskell but considered bad style /
bad practice for packages. I’m not sure if the norms in O’Caml reflect the
same inclination. This may complicate localizing type errors
On Thu, May 31, 2018 at 11:51 AM davean
My experience may not be representative, but I've done waves of updating packages for a new 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.
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.
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).
-davean
On Thu, May 31, 2018 at 5:32 AM, Sébastien Hinderer < Sebastien.Hinderer@inria.fr> wrote:
Dear all,
I am part of the OCaml development team. As you may know, OCaml has a package manager a bit similar to cabal whose name is opam.
One of my colleagues spends quite a lot of time trying to make sure that packages still compile with a new version of the compiler, when we release it. When a package does not compile any longer, it seems it is a highly non-trivial task to figure out what exactly is broken: is it the package itself which has been broken by a change in the compiler, or is it one of its dependencies.
I am assuming the same kind of problems occur with Haskell and am wondering how they are handle.
Has there been something published on this kind of problem?
Any pointer, comment or contact appreciated.
Best wishes,
Sébastien. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users