[Haskell] Re: QuickCheck revival and Cabal

[Simon Marlow]

Koen Claessen wrote:

> For the past couple of years, I have been quietly hacking on a brand new
> version of QuickCheck with lots of cool features. I have been
> distributing copies to some friends, but have not released any official
> package.
> 
> Now, after lots of peer pressure, the time has come that I want to
> release the current version as a Cabal package.
> 
> I have been agonizing however over where in the module hierarchy the new
> QuickCheck package should be.
> 
> There is currently an old QuickCheck version in the standard hierarchy
> in Test.QuickCheck. As the new QuickCheck is incompatible with the old
> one, I do not want to override that place. Rather, I would like to
> create my own little space in the hierarchy where the new version can
> sit and develop.
> 
> It feels to me that there should be a convention that people use to add
> their own contributions to the module hierarchy without the danger of
> clashing with other packages.
> 
> Proposals:
> 
>   Contrib.Chalmers.QuickCheck
>   External.Chalmers.QuickCheck
>   Chalmers.QuickCheck
>   Contrib.Test.QuickCheck
>   Contrib.QuickCheck

If you intend the new version as a replacement for the old, then it 
should be called Test.QuickCheck, and the package should identify itself 
as a newer version (2.0, or whatever).  It's possible to have multiple 
versions of a package simultaneously installed (at least with GHC). 
Currently it isn't possible to use them both in the same program, but we 
intend to allow that in the future.

If you have both QuickCheck-1.0 and QuickCheck-2.0 installed, typically 
the new one will be the default, and the old one will be available if 
you explcitly say '-package QuickCheck-1.0', or if you specify a 
dependency on QuickCheck-1.0 in a .cabal file.

Frederik mentioned "mounting", a concept which is also known as 
"grafting", which would allow you the user to move modules around in the 
hierarchy, and it would free the package author from deciding once and 
for all what absolute module names to use.  This is the direction we 
plan to go in for GHC, I'm not sure when it will happen though.

Cheers,
	Simon