Testing that packages still compile

Carter Schonwald carter.schonwald at gmail.com
Thu May 31 18:53:34 UTC 2018


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 <davean at 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.Hinderer at 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20180531/f18ae70b/attachment.html>


More information about the Glasgow-haskell-users mailing list