Re: [Haskell] QuickCheck revival and Cabal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell] QuickCheck revival and Cabal

Jean-Philippe Bernardy
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 <[hidden email]> wrote:

> 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
> > [hidden email]
> > http://www.haskell.org/mailman/listinfo/haskell
> >
>
> --
> http://ofb.net/~frederik/
> _______________________________________________
> Haskell mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries