indeed.

So lets think about how to add module types or some approximation thereof to GHC? (seriously, thats the only sane "best solution" i can think of, but its not something that can be done casually). Theres also the fact that any module system design will have to explicitly deal with type class instances in a more explicit fashion than we've done thus far.


On Tue, Feb 25, 2014 at 12:17 PM, Vincent Hanquez <tab@snarc.org> wrote:
On 2014-02-25 15:12, Brandon Allbery wrote:

On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman <michael@snoyman.com <mailto:michael@snoyman.com>> wrote:

    But that's only one half of the "package interoperability" issue.
    I face this first hand on a daily basis with my Stackage
    maintenance. I spend far more time reporting issues of restrictive
    upper bounds than I do with broken builds from upstream changes.
    So I look at this as purely a game of statistics: are you more
    likely to have code break because version 1.2 of text changes the
    type of the map function and you didn't have an upper bound, or
    because two dependencies of yours have *conflicting* versions
    bounds on a package like aeson[2]? In my experience, the latter
    occurs far more often than the former.


I have a question for you.

Is it better to save a developer some work, or is it better to force that work onto end users?

As a *user* of many libraries, I had more problems with libraries that follow the PvP religiously than the other way around. I usually like to have the latest and greatest libraries, specially text, aeson, and such, and there I have to manually bump dependencies of packages I depend on, until the developers gets to update the package on hackage (which sometimes takes many weeks).

As a *developer*, following the PvP would cost me a lot of my *free* time. This is particularly true when the surface of contact with a library is small, it's very unlikely that I will run into an API changes. When I do, I release a new package quickly that account for the API change, or I can put a upper bounds if I can't make the necessary changes quickly enough. I usually found out quite quickly with stackage nowadays, most of times, before any users get bitten.

Some other time, I'm testing some development ghc or some new unreleased libraries, and I need to remove upper bounds from packages so that I can test something.

Anyway, there's lots of reason that the PvP doesn't works fully. It solves some problems for sure, but sadly swipe all the other problems under the carpet. One problem being that a single set of numbers doesn't properly account for API complexity and stability that might differ in different modules of the same package.

--
Vincent

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries