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