The only time people seem to get into trouble with too restrictive lower bounds is if they are using a global/user package db along with the haskell platform where the versions of some packages are pegged. Common best practice seems to be to support the last two haskell platform releases, and that's pretty easy to test against.

As a user it very seldom causes problems when a package is missing lower bounds. One of the strengths of having upper bounds is that you have an easier time installing old versions of packages if you need to. When doing that Cabal (as always) picks the latest versions of dependencies so the lower bound doesn't matter.

That said I always add some arbitrary (but tested) lower bound for my packages nowadays. I've never gotten asked to relax it so it doesn't seem to be a problem in practice.

On Sat, Jul 5, 2014 at 9:59 PM, Edward Z. Yang <ezyang@mit.edu> wrote:

Hello Omari,

This problem is among several that I am hoping to address with
the module system work that I am doing this summer at MSR.

The basic algorithm we are planning on implementing calculates a minimal
library signature which a package would correctly type-check against,
and then checks whether or not versions of the library implement this
signature. A simple version of this check is not hard to do if
you hook in to GHC after the renaming pass (but considerably more
difficult if you have to implement it from scratch: renaming is fairly
nontrivial). Our approach is efficient: once the signature is computed,
it is no longer necessary to typecheck the package to test for
compatibility.

There are a few things our approach won't handle: for example,
if a signature is made more polymorphic, in a way that the program
still compiles, we will flag it as a mismatch (the plan is to simply
require the types be the same.)

Cheers,
Edward

Excerpts from Omari Norman's message of 2014-07-05 20:37:14 +0100:

> Often a topic of discussion is making sure that the upper bounds on one's
> packages are up to date, or even whether upper bounds are a good idea at
> all.
>
> I don't see much discussion on lower bounds. Lower bounds that are
> needlessly restrictive can get in the way too. For instance, I could just
> slap "text >= 1.1 && < 1.2" on my package, but this makes things needlessly
> hard for someone trying to make my package work in conjunction with an
> older one, especially if all I use are basic functions like "pack" that
> have been around at least since, say. text-0.11.
>
> Does anyone have a best practice for testing and verifying lower bounds?
> Testing the lower bounds and the upper ones is a challenge. Does anybody
> bother? I have my sunlight package at
>
> http://hackage.haskell.org/package/sunlight
>
> but it is really a nasty hack. I am considering cleaning it up so it is
> less of a nasty hack but before I do that I wondered if anyone else has
> ever thought about this problem.
>
> Thanks.
> Omari

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe