Hello,
I think Cabal supports versioning. If QuickCheck2 is a superset of
QuickCheck1, one can expect people won't use both at a time. Therefore
it seems natural to just re-use the package name, module names, etc.
and just use cabal's versioning.
My 2 cents,
JP.
On 4/11/06, Frederik Eaton
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
-- http://ofb.net/~frederik/ _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell