Paul Johnson wrote:

Felix Martini wrote:

...

This patch contains a module GenT for QuickCheck 2. GenT is a monad transformer variant of the Gen monad.

I'm a bit puzzled because I already submitted a similar patch myself, but hadn't heard anything.

Here it is again.

On Sun, 2007-08-12 at 21:36 +0100, Ian Lynagh wrote:

I'm not sure * why extralibs still uses QC1, * whether QC2 is ready for production use, or * whether QC is actively maintained. Any light would be greatly appreciated!

And one thing about it which concerns me somewhat is that it seems to want to remain compatible with old versions of things at the expense of taking advantage of new features in the current libraries. That might make sense for a package that is independently distributed but not for one that is bundled with Haskell implementations and the latest versions of all dependent libraries. My concrete example is that I submitted patches to make Gen an instance of Applicative but was told this wasn't ok since it needed to remain compatible with ghc-6.2 or something. IMOH, if it's part of the core set of packages it should be ok to depend on those packages. If QC (either 1 or 2) it is governed by the library submission process then I'll resubmit my patches with an appropriate proposal. Duncan

Duncan Coutts wrote:

...

And one thing about it which concerns me somewhat is that it seems to want to remain compatible with old versions of things at the expense of taking advantage of new features in the current libraries.

And it disappoints me, when software demands the latest (often unreleased) version of something else (compiler,lib), just to take advantage of some new feature that 90% of users are not interested in anyway. There is always a tension between stability - supporting and retaining existing users - and feature-creep.

...

My concrete example is that I submitted patches to make Gen an instance of Applicative but was told this wasn't ok since it needed to remain compatible with ghc-6.2 or something.

Isaac Dupree wrote:

Personally, I don't see the need for new versions of libraries to stay compatible with such old versions of GHC (is there a specific old-ghc use case I'm unaware of?).

Yes. The default version of ghc provided by our local tech support people for the use of all students and staff (i.e. those who are not specifically researching Haskell) is ghc-6.2.2. They have a huge number of software packages to maintain, and so their upgrade cycle is necessarily slow. Now these (mostly novice) users of Haskell are the ones who are mostly quickly going to give up in disgust if some piece of software they download from the 'net fails to build because it requires newer versions of all kinds of things they have not even heard of. Bleeding edge dependencies are fine for those who know and like Haskell. For those people who are just trying to get their job done, they want software to "just work" out-of-the-box, regardless of which compiler version they happen to have available, which probably isn't even under their control. Another use-case is for obsolete machines like sparc-Solaris, where e.g. the most recent (working) binary distribution that I can find is ghc-6.2.1. Any newer version needs dependencies like readline-5, gmp-4, which are more recent than anything I can obtain for solaris. Well, I'm sure it would not be completely impossible to chase everything down and build it myself, but I gave up after a day or two. Regards, Malcolm

On Wed, Aug 15, 2007 at 03:18:04PM +0200, Henning Thielemann wrote:

Actually, after a test of GHC-6.6 I do not want to update because file name completion was replaced by identifier completion.

The current code tries to do both filename and identifier completion, but it would benefit from some tweaking. Thanks Ian

I think one has to be realistic about the state of the language and the speed of the development of the compiler, bundled libraries, unbundled libraries, and related tools. While I've been able to do substantial commercial development in Haskell using GHC, I don't expect seamless updates. Sure, this adds work, but my opinion is that it is manageable and that the majority of changes are worthwhile. Like anyone else, I might have made somewhat different choices in a few cases, but I don't think that any sort of blanket condemnation is justified. Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface -----Original Message----- From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Duncan Coutts Sent: Wednesday, August 15, 2007 9:34 AM To: Malcolm Wallace Cc: libraries@haskell.org Subject: Re: stability vs latest features (was: Re: darcs patch: GenT monad transformer variant of Gen (QuickCheck 2)) On Wed, 2007-08-15 at 13:26 +0100, Malcolm Wallace wrote:

Isaac Dupree wrote:

...

Personally, I don't see the need for new versions of libraries to stay compatible with such old versions of GHC (is there a specific old-ghc use case I'm unaware of?).

Yes. The default version of ghc provided by our local tech support people for the use of all students and staff (i.e. those who are not specifically researching Haskell) is ghc-6.2.2.

But that version of GHC comes with libraries that work with it. I'm talking about libs that get bundled with the implementation, it should be ok for them to depend on the versions of other libs that get bundled with the implementation. For programs or libraries distributed independently it's up to the package author to decide how much effort they want to go to to ensure the package builds with a wide range of implementations and library versions. Cabal configurations should make this situation better. Cabal does support ghc back to 6.2.2 and with a suitable .cabal file it should be possible to make most progs work with a range of compiler versions. BTW, re ghc on Sparc Solaris, it does build from source, we've got ghc 6.4.1 on our Sparc Solaris9 machines in Oxford. Duncan _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Stefan O'Rear wrote:

On Wed, Aug 15, 2007 at 02:34:22PM +0100, Duncan Coutts wrote:

...

Cabal configurations should make this situation better. Cabal does support ghc back to 6.2.2 and with a suitable .cabal file it should be possible to make most progs work with a range of compiler versions.

I'm not so sure. Cabal configurations look like they will fix the problem, but given a few years every .cabal file out there will look like a pre-autoconf C program's config.h, just a huge tangle of feature tests and conditional module usages...

I'd much prefer a situation where the (much smaller number of) library authors carry the burden of compatibility; maybe something like

{- in base-2.0's .cabal -}

Provides: fps-1.0 by { Data.ByteString* }

Do we need to cater to situations in which Cabal, or old packages' .cabal files, aren't upgradable? I'd guess not, because then why would you be able to install newer packages that need any of this, either? Assuming we don't... New versions should depend on whatever the newest name for the package is (e.g. "bytestring"). There are old names like "base" and "fps" that provide older versions of the same thing. Somehow (update their cabal files? Bake knowledge into a centralized place like a part of Cabal?) these names should be translated so that (requiring bytestring in GHC 6.6) pulls in (base) instead...... too bad for programs that need a newer version of ByteString perhaps? Or, a "bytestring" might be installable...

... which unfortunately doesn't handle splits (FiniteMap etc) anywhere near as well.

Why have package names, again? It seems using modules names instead would completely fix this problem, and with the small restriction that a module name, once used, is not reused for something incompatible, solves the versioning problem as well.

1. upgrades make incompatibility anyway, sometimes 2. sometimes it is (or should be? or is likely to be, sometime in future?) decided that a module change is for the better 3. module Main... (divergent leaves are not a problem as long as it remains a tree, not generally an acyclic graph, of dependencies; module Main dep. on (A which dep. on C{-1-}) and (B which dep. on C{-2-}) won't work in ghc<6.6 and I don't know about other Haskell implementations) Module names allow you to have sort-of-broken packages and libraries without them interfering with normal package usage. Package and dependency renaming can be performed without any change to Haskell source code, which is viewed as a desirable partitioning. Isaac

On Thu, Aug 16, 2007 at 09:29:28PM +0200, Thomas Schilling wrote:

On 15 aug 2007, at 20.20, Stefan O'Rear wrote:

...

I'd much prefer a situation where the (much smaller number of) library authors carry the burden of compatibility; maybe something like

{- in base-2.0's .cabal -}

Provides: fps-1.0 by { Data.ByteString* }

... which unfortunately doesn't handle splits (FiniteMap etc) anywhere near as well.

How far would re-exporting imported modules bring us? This would allow some sort of "virtual" packages (put in quotes, because I don't know how much this reflects the usage of this term in, e.g., Gentoo), which could at least solve package splits quite nicely.

Assume we have base-2.0. Then the .cabal for base-1.0 could look somewhat like:

build-depends: base >= 2.0, filepath, {- ... -} exposed-modules: Data.ByteString*, System.FilePath*, {- ... -}

Hmm, good point. I like it. (I do think it would work much better if Cabal had a better notion of version numbers that includes forward compatibility and suchlike - don't ever satisfy a 1.0.0 request with 2.x.y, etc)...

I really don't like hacks with configurations like

if flag(small_base) { build-depends: base >= 2.0, filepath >= 1.0, ... } else { build-depenhs: base >= 1.0 && base < 2.0 }

since they have to be put in _every_ .cabal file.

And fragile, too - when someone tries to build on GHC 6.4 for the first time, that misspelled field will cause major headaches :) Stefan

On Sun, Aug 12, 2007 at 11:00:47PM +0100, Duncan Coutts wrote:

My concrete example is that I submitted patches to make Gen an instance of Applicative but was told this wasn't ok since it needed to remain compatible with ghc-6.2 or something.

You could do this with ifdefs.

IMOH, if it's part of the core set of packages it should be ok to depend on those packages.

It's not a core package as far as GHC is concerned. Thanks Ian