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 <dav...@xkcd.com> wrote: > 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.hinde...@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 >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users