[Haskell-cafe] Checking minimum package bounds

[Edward Z. Yang]

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