Dear all, 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 The first three I like -- but not the last one; I don't want to rule out anyone else (except for my own colleagues :-) making their own version of QuickCheck and releasing it somewhere in the tree. What does one think? Regards, /Koen PS1. Previously discussions about this were referred to the libraries mailing list but I feel that this is of interest to the larger crowd too. PS2. I welcome myself back to the Haskell mailing list after years of inactivity :-)
Hi, Why not just call it, say, Test.QuickCheck2? I think module names should reflect only their functionality. I don't see how "External" or "Contrib" or "Chalmers" would say anything useful about the functionality of the modules. A while ago I sent a proposal for "package mounting", which I think would let us avoid this whole issue: http://www.haskell.org//pipermail/libraries/2005-June/004009.html I am opposed to a situation such as Java's, in which every module is permanently fixed somewhere in a huge module hierarchy, for the reasons I describe in the proposal (namely, in part because I don't think that global-name-choosing should be such a fundamental part of coding - as you said, it is a source of agony). The proposal was an attempt to describe an alternative approach. I think the ideal solution would be: - Your code is released in a package with modules named "Batch", "Poly", "Utils", etc., i.e. with no qualification. - The package has a default mount point of Test.QuickCheck. If people want the old version, then they can specify the old package instead of the new package on the compiler/interpreter command line. The response to my proposal was semi-positive, but I don't think any work has gone towards implementing it (certainly not by myself). Cheers, Frederik On Tue, Apr 11, 2006 at 01:02:51PM +0200, Koen Claessen wrote:
Dear all,
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
The first three I like -- but not the last one; I don't want to rule out anyone else (except for my own colleagues :-) making their own version of QuickCheck and releasing it somewhere in the tree.
What does one think?
Regards, /Koen
PS1. Previously discussions about this were referred to the libraries mailing list but I feel that this is of interest to the larger crowd too.
PS2. I welcome myself back to the Haskell mailing list after years of inactivity :-)
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
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
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.
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.
The new QuickCheck is not a replacement for the old. For one, it is incompatible (in some trivial ways, but still). I don't want peoples programs or other libraries to break just because they rely on the old QuickCheck.
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.
OK. So, I'll just decide an arbitrary name/place and then later migrate to this new thing. /Koen
Koen Claessen (Wed, Apr 12, 2006 at 11:06:50AM +0200):
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.
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.
The new QuickCheck is not a replacement for the old. For one, it is incompatible (in some trivial ways, but still). I don't want peoples programs or other libraries to break just because they rely on the old QuickCheck.
An increase in the major version number used to show that the new version is incompatible with the old one. Extensions left the major version number unchanged and increase the minor version number. major change : 1.0 -> 2.0 minor change : 1.0 -> 1.1 bugfix change: 1.0.0 -> 1.0.1 So a Cabal package QuickCheck-2.0 should be ok. If you install it, you should expect incompatibilities. Regards, -- Stefan
participants (4)
-
Frederik Eaton -
Koen Claessen -
Simon Marlow -
Stefan Karrmann