- cabal-devel - Haskell.org

ANN: Cabal-1.16.0.2 and cabal-install-1.16.0.1
by Johan Tibell 24 Oct '12

24 Oct '12

Hi, On behalf of the cabal contributors, I'm proud to announce bugfix releases of Cabal and cabal-install. Here's a complete list of changes since the last release: Since Cabal-1.16.0.1: * Bump Cabal version number to 1.16.0.2 * Fixed warnings on the generated Paths module. The warnings are generated by the flag '-fwarn-missing-import-lists'. Since cabal-install-1.16.0: * Have bootstrap.sh use Cabal-1.16.0.2 * Fix installing from custom folder on Linux (#1058) * Change bootstrap.sh to require Cabal >= 1.16 && < 1.18 * Bump cabal-install version number to 1.16.0.1 * Bump network dependency in bootstrap.sh to 2.3.1.1 * Fix compilation error * Disable setting the jobs: $nprocs line in default ~/.cabal config * Fix building cabal-install with ghc-6.12 and older I expect this to be the last release from the 1.16 branch. I intend to make another in about 3 months, or a bit sooner if the sandboxing work is ready earlier. Cheers, Johan

1 0

RE: deprecating
by Simon Peyton-Jones 23 Oct '12

23 Oct '12

| > It's an interesting question: does Rank2Types mean "I require at | > least | > rank-2 types" or "I only use rank-2 types"? | | I think it means "I require at least rank-2 types". | | To clarify, I think it's OK if a compiler accepts a program marked | "Rank2Types" and incorrectly not marked "RankNTypes" when it actually | requires rank-n types. In every other flag it means the reverse of this. For example if I say -XGADTs I mean "This program uses the GADT feature, and can be compiled by any program supporting GADTs. It does not use kind polymorphism or type families, and if it turns out that the program *does* use those features it should be rejected". So to accept a program with a rank-3 type with a flag saying Rank2Types would be, well, inconsistent. But someone said that foolish consistency is the hobgoblin of tiny minds, so if everyone things it's better to be inconsistent than to nudge package authors with deprecations, I can live with that. (But I still think it's strange to have deprecations but to treat them as errors. We could instead get rid of deprecations altogether and just say "oldFunction not in scope"!) I doubt this is worth more of our time. I'll just make Rank2Types and PolymorphicComponents a synonym for RankNTypes, and document that infelicity. Simon

1 0

Re: deprecating
by Simon Marlow 23 Oct '12

23 Oct '12

On 22/10/2012 19:15, Ashley Yakeley wrote: > On 22.10.2012 11:05, Johan Tibell wrote: > >>> I think it's OK if a compiler accepts a program incorrectly marked >>> "Rank2Types" when it actually requires rank-n types? >> >> It's an interesting question: does Rank2Types mean "I require at least >> rank-2 types" or "I only use rank-2 types"? > > I think it means "I require at least rank-2 types". > > To clarify, I think it's OK if a compiler accepts a program marked > "Rank2Types" and incorrectly not marked "RankNTypes" when it actually > requires rank-n types. I don't think I understand why you would want an extension flag to mean "at least" rather than "at most". No other extension flag works that way. If you take that view to its logical conclusion, we would never need to specify any extension flags at all. Rank2Types is only useful if it really means rank-2 types, which it apparently doesn't, so I'm quite happy to deprecate it. We don't have to actually remove it for a long time, since the cost of maintaining one flag that is a synonym for another flag is small. Cheers, Simon

1 0

Re: deprecating
by Simon Marlow 23 Oct '12

23 Oct '12

On 23/10/2012 09:04, Roman Leshchinskiy wrote: > Bryan O'Sullivan wrote: >> On Mon, Oct 22, 2012 at 4:14 PM, Simon Peyton-Jones >> <simonpj(a)microsoft.com>wrote: >> >> >>> Do you mean “silently and forever”? >>> >> >> I think that's what I mean, yes. >> >> As Johan notes, many of us run our continuous builds of our packages with >> -Wall -Werror in order to keep them as clean as possible. Introducing a >> deprecation thus forces me into some kind of response as my builds all >> suddenly fail: I can either turn off -Werror for a package, or edit the >> affected source files. > > It seems to me that hard-coding -Werror in source distributions is a > mistake since it serves no real purpose other than breaking the package > for everyone whenever a compiler introduces a new warning. You can compile > with -Werror while developing, of course. But why have -Werror in the > release? Quite right, shipping code with -Werror turned on is definitely a bad idea. I think Hackage and/or Cabal will complain if you try to do this. Cheers, Simon

1 0

Re: deprecating
by Johan Tibell 22 Oct '12

22 Oct '12

On Mon, Oct 22, 2012 at 11:02 AM, Ashley Yakeley <ashley(a)semantic.org> wrote: > I think it's OK if a compiler accepts a program incorrectly marked > "Rank2Types" when it actually requires rank-n types? It's an interesting question: does Rank2Types mean "I require at least rank-2 types" or "I only use rank-2 types"?

1 0

RE: deprecating
by Simon Peyton-Jones 22 Oct '12

22 Oct '12

| I thought the point of these extension flags was to be cross-compiler? | So it seems a bit odd to make a change for the benefit of one compiler. | | Here's my interpretation: Rank2Types is not a synonym for RankNTypes. | It's a specific requirement the source file has. When GHC comes to | compile it, it can satisfy that requirement by switching on its | RankNTypes. Another compiler might support Rank2Types but not | RankNTypes, and it would also be able to compile the file. The trouble is that it's painful to check that a program uses rank-2 *only*, which is what you might naively think of the flag. So rather than fiddle about with distinctions that no one really cares about, the idea is to abolish the distinction. But if the will of the masses is to silently and forever make Rank2Types=RankNtypes (documented of course), that's ok with me. It just seems odd. I thought that's what deprecation was *for*. Simon | | -- Ashley | | On 19/10/12 09:53, Simon Peyton-Jones wrote: | > See my response on | > http://hackage.haskell.org/trac/ghc/ticket/6032#comment:6 | > Not sure what the best path is here | > | > S | > | > | -----Original Message----- | > | From: Johan Tibell [mailto:johan.tibell@gmail.com] | > | Sent: 19 October 2012 17:39 | > | To: Simon Peyton-Jones | > | Cc: Don Stewart; Duncan Coutts; Roman Leshchinskiy; | > | ashley(a)semantic.org; cabal-devel(a)haskell.org; Ben Lippmeier; Manuel | > | M T Chakravarty; cvs-ghc(a)haskell.org | > | Subject: Re: deprecating | > | | > | Hi Simon, | > | | > | On Fri, Oct 19, 2012 at 4:49 AM, Simon Peyton-Jones | > | <simonpj(a)microsoft.com> wrote: | > | > As discussed in Trac #6032 I am deprecating | > | > | > | > Rank2Types | > | > | > | > PolymorphicComponents | > | > | > | > in favour of the single flag | > | > | > | > RankNTypes | > | | > | I'm fine with making the changes to cabal, but before I do, I want | > | to make sure that we really want to do this. I did a quick | > | investigation of how many modules need to be updated on Hackage. | It's about 775. | > | That will require quite a lot of work by quite a lot of people. | > | Could we instead have Rank2Types be an alias for RankNTypes? | > | | > | Cheers, | > | Johan | > | > |

2 1

deprecating
by Simon Peyton-Jones 22 Oct '12

22 Oct '12

Dear maintainers of bytestring cabal vector time dph As discussed in Trac #6032 I am deprecating Rank2Types PolymorphicComponents in favour of the single flag RankNTypes Could you update your packages to match? Until then we'll need to accept the deprecation warnings that GHC will produce when building them. The change is backward compatible; older GHCs understand RankNTypes. In addition to changing any LANGAUGE pragmas, there may be some changes to Cabal's flaggery. Thanks Simon ./Cabal/Cabal/Distribution/PackageDescription/Check.hs:1114: , RankNTypes, PolymorphicComponents, ExistentialQuantification ./Cabal/Cabal/Distribution/Simple/GHC.hs:459: ,(PolymorphicComponents , fglasgowExts) ./Cabal/Cabal/Distribution/Simple/Hugs.hs:194: ,(PolymorphicComponents , ext98) ./Cabal/Cabal/Distribution/Simple/UHC.hs:103: (PolymorphicComponents, alwaysOn), ./Cabal/Cabal/Language/Haskell/Extension.hs:186: | PolymorphicComponents ./bytestring/Data/ByteString/Builder/Internal.hs:1:{-# LANGUAGE ScopedTypeVariables, CPP, BangPatterns, Rank2Types #-} ./Cabal/Cabal/Distribution/PackageDescription/Check.hs:1113: , FunctionalDependencies, Rank2Types ./Cabal/Cabal/Distribution/Simple/GHC.hs:457: ,(Rank2Types , fglasgowExts) ./Cabal/Cabal/Distribution/Simple/Hugs.hs:193: ,(Rank2Types , ext98) ./Cabal/Cabal/Distribution/Simple/UHC.hs:108: (Rank2Types, alwaysOn), ./Cabal/Cabal/Language/Haskell/Extension.hs:177: | Rank2Types ./containers/Data/Graph.hs:3:{-# LANGUAGE Rank2Types #-} ./dph/dph-lifted-copy/Data/Array/Parallel/Lifted/TH/Repr.hs:1:{-# LANGUAGE TemplateHaskell, Rank2Types #-} ./time/Data/Time/Calendar/Days.hs:13:#if LANGUAGE_Rank2Types ./time/Data/Time/Calendar/Days.hs:20:#if LANGUAGE_Rank2Types ./time/Data/Time/Clock/Scale.hs:19:#if LANGUAGE_Rank2Types ./time/Data/Time/Clock/Scale.hs:27:#if LANGUAGE_Rank2Types ./time/Data/Time/Clock/Scale.hs:45:#if LANGUAGE_Rank2Types ./time/Data/Time/Clock/TAI.hs:24:#if LANGUAGE_Rank2Types ./time/Data/Time/Clock/TAI.hs:31:#if LANGUAGE_Rank2Types ./time/Data/Time/Clock/UTC.hs:23:#if LANGUAGE_Rank2Types ./time/Data/Time/Clock/UTC.hs:37:#if LANGUAGE_Rank2Types ./time/Data/Time/Clock/UTC.hs:66:#if LANGUAGE_Rank2Types ./time/Data/Time/Format/Parse.hs:8:#if LANGUAGE_Rank2Types ./time/Data/Time/Format/Parse.hs:21:#if LANGUAGE_Rank2Types ./time/Data/Time/Format/Parse.hs:30:#if LANGUAGE_Rank2Types ./time/Data/Time/Format/Parse.hs:34:#if LANGUAGE_Rank2Types ./time/Data/Time/Format/Parse.hs:64:#if LANGUAGE_Rank2Types ./time/Data/Time/Format/Parse.hs:344:#if LANGUAGE_Rank2Types ./time/Data/Time/LocalTime/LocalTime.hs:22:#if LANGUAGE_Rank2Types ./time/Data/Time/LocalTime/LocalTime.hs:35:#if LANGUAGE_Rank2Types ./time/Data/Time/LocalTime/LocalTime.hs:79:#if LANGUAGE_Rank2Types ./time/Data/Time/LocalTime/TimeOfDay.hs:19:#if LANGUAGE_Rank2Types ./time/Data/Time/LocalTime/TimeOfDay.hs:34:#if LANGUAGE_Rank2Types ./time/Data/Time/LocalTime/TimeZone.hs:24:#if LANGUAGE_Rank2Types ./time/Data/Time/LocalTime/TimeZone.hs:38:#if LANGUAGE_Rank2Types ./vector/Data/Vector/Fusion/Stream/Monadic.hs:1:{-# LANGUAGE ExistentialQuantification, Rank2Types, BangPatterns #-} ./vector/Data/Vector/Fusion/Stream.hs:1:{-# LANGUAGE FlexibleInstances, Rank2Types #-} ./vector/Data/Vector/Generic/Base.hs:1:{-# LANGUAGE Rank2Types, MultiParamTypeClasses, FlexibleContexts, ./vector/Data/Vector/Generic/New.hs:1:{-# LANGUAGE Rank2Types, FlexibleContexts #-} ./vector/Data/Vector/Generic.hs:1:{-# LANGUAGE Rank2Types, MultiParamTypeClasses, FlexibleContexts, ./vector/Data/Vector/Primitive.hs:1:{-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, TypeFamilies, ScopedTypeVariables, Rank2Types #-} ./vector/Data/Vector/Storable.hs:1:{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, TypeFamilies, Rank2Types, ScopedTypeVariables #-} ./vector/Data/Vector/Unboxed.hs:1:{-# LANGUAGE Rank2Types #-} ./vector/Data/Vector.hs:1:{-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, TypeFamilies, Rank2Types #-}

5 8

Output of cabal sandbox commands
by Johan Tibell 16 Oct '12

16 Oct '12

Hi, If we're going to be using sandboxes extensively (I think we should!) having each command output the sandbox location is a bit much. Perhaps make this line: Using a sandbox located at /Users/tibbe/src/cassava/.cabal-sandbox only appear at higher verbosity? I think we should output something when we first create the sandbox: Created a sandbox located at /Users/tibbe/src/cassava/.cabal-sandbox What do you think? -- Johan

2 3

cabal-install-1.16.0.2
by Johan Tibell 15 Oct '12

15 Oct '12

Hi all, I've created bug fix release candidates for Cabal and cabal-install to address the bugs found after the release. If everyone could take some time to try them out, especially those who had issues with the previous releases. To install the release candidates run: cabal install http://johantibell.com/files/Cabal-1.16.0.2.tar.gz \ http://johantibell.com/files/cabal-install-1.16.0.1.tar.gz Unless there are any issues, we'll make a release in the next few days. Cheers, Johan

2 2

Re: [Haskell-cafe] ANN: cabal-install-1.16.0 (and Cabal-1.16.0.1)
by Johan Tibell 08 Oct '12

08 Oct '12

Hi, I'll make a bugfix release for cabal-install and Cabal in a few days to include fixes to issues people found so far. If everyone who had some problem related to the latest release could please post it here so I can make sure that we include a fix for them. If you've already reported it elsewhere, please bring it up here anyway to make sure I don't miss it. -- Johan

2 1