qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method)

[Carter Schonwald]

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 at snarc.org> wrote:

> On 2014-02-25 15:12, Brandon Allbery wrote:
>
>  On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman <michael at snoyman.com<mailto:
>> michael at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140225/53e983f1/attachment-0001.html>