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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
