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 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

Herbert's wonderful multi ghci Travis let's you test on all the configs https://github.com/hvr/multi-ghc-travis On Monday, July 7, 2014, Alois Cochard wrote:

On 6 July 2014 01:11, Adam Bergmark javascript:_e(%7B%7D,'cvml','adam@bergmark.nl');> wrote:

...

Common best practice seems to be to support the last two haskell platform releases, and that's pretty easy to test against.

Actually, how do you do that?

It's a shame that the platform is not a 'hackage' package, otherwise I could simply install it in a sandbox... But how can I test my app for a specific platform without reinstalling my local/global DB?

For now I'm going on the platform github repo to get the versions, I put them as lower bound and then I use Omari's sunlight.

I actually use Herbert's other wonderful tool: the Ubuntu PPAs for GHC. Then I just switch by PATH to point to whichever version of GHC I want to test at at that time. Before I switched to the PPAs, I simply installed multiple versions of GHC in their own directories under /opt. On Mon, Jul 7, 2014 at 5:55 PM, Alois Cochard wrote:

That is neat!

But I would rather have a solution that don't involve The Cloud, which I can run locally without setting up a local travis.

Seems like the time to learn docker have now come :-)

On 7 July 2014 15:52, Carter Schonwald wrote:

...

Herbert's wonderful multi ghci Travis let's you test on all the configs https://github.com/hvr/multi-ghc-travis

On Monday, July 7, 2014, Alois Cochard wrote:

...

On 6 July 2014 01:11, Adam Bergmark wrote:

...

Common best practice seems to be to support the last two haskell platform releases, and that's pretty easy to test against.

Actually, how do you do that?

It's a shame that the platform is not a 'hackage' package, otherwise I could simply install it in a sandbox... But how can I test my app for a specific platform without reinstalling my local/global DB?

For now I'm going on the platform github repo to get the versions, I put them as lower bound and then I use Omari's sunlight.

-- *A\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

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