qualified imports, PVP and so on

[Edward Kmett]

I very much agree with the sentiment that bounds on, say, template-haskell
or ghc-prim never help build plans.

One of the most common complaints I get from users has to do with the
garbage type errors they get out of the template-haskell that runs lens
when some package somewhere has "upgraded" their `template-haskell` install
to a non-compatible version.

By the time they discover this they are often several packages further
along in the install and only have the vaguest inkling of what caused the
problem in the first place.

Regarding base I still use the < 5 bound, as as Herbert pointed out if we
ever needed to ship with support for two versions of base during some big
cut-over, it'd be nice to have it work. That said, I'm somewhat leery of
how well the community could deal with that in practice. Even the old
monads-fd vs mtl split nearly rent the ecosystem asunder. ;)

-Edward


On Wed, Feb 26, 2014 at 7:09 AM, Michael Snoyman <michael at snoyman.com>wrote:

>
>
>
> On Wed, Feb 26, 2014 at 2:03 PM, Johan Tibell <johan.tibell at gmail.com>wrote:
>
>> I think we should relax the PVP requirement to bump the major version
>> number when adding an instance and instead require that the major version
>> bump is only required when using orphan instances and otherwise only a
>> minor version bump is required. Unless I missed some case, code that
>> depends on a library that follows this rule should not not break.
>>
>> Here's my reasoning:
>>
>> If you add a non-orphan instance, it must be because
>>
>>  * you define the data type or the type class in your package and
>>  * depend on a package that declares the other entity.
>>
>> Therefore, no package that depend on your package can declare a
>> non-orphan instance that could collide with the instance you declare.
>>
>>
>>
> +1. If we're discussing PVP changes, the other one I'd like to propose is:
>
> Don't include upper bounds on base, template-haskell, or other libraries
> which cannot be upgraded, unless you know with certainty that your package
> will not compile with those other versions. Motivation:
>
> * The bounds will never help cabal choose a better build plan.
> * The bounds may cause valid builds to never be attempted.
> * The bounds make it very difficult to check and debug new versions of GHC.
> * Including the bounds if you know the build will fail makes for more
> user-friendly messages.
> * Leaving off the bounds if you're not certain will result in users
> getting more verbose error messages. While uglier, these error messages
> will be helpful for the package maintainer to adjust the package for the
> new version of GHC.
>
> I'd also want to push the bounds a little bit further a make a distinction
> between experimental and stable packages, but that's a bigger proposal and
> I'd rather start with something more modest.
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140226/b81f3b3d/attachment.html>