Upgrading packages/Updating to GHC 6.10
(Mentioned "Exception handling" problems)
(Added instructions for handling Arrow changes)
Revision as of 17:45, 11 October 2008
A list of things that need updating when porting packages to newer library/cabal versions.
If you maintain a Haskell package this is for you. For older versions of this document:
Updating to GHC 6.10 and Cabal 1.6
When upgrading to GHC 6.10, any of your packages that worked against the base-3 library will continue to work. GHC 6.10 provides both the old base-3 library and the new base-4.
To ensure your old code continues to work, you can have the code compile and link against base-3, and then, over time, migrate code to the base-4 series.
1 Adding base-3 constraints
How to do this depends on how you build your Haskell code. We'll start with the most simplistic build mechanisms. cabal-install, the most sophisticated tool, will sort this all out for you anyway, so things should change.
1.1 ghc --make
Force use of package base-3 when using --make,
ghc --make --package base-18.104.22.168
If you build your packages with the 'runhaskell Setup.hs configure' method, then you can force the use of base-3,
It is worth upgrading cabal-install immediately (maybe before installing GHC). This way you can use the smart dependency solver to work out what to install for you.
Then build cabal-install.
You can also override the dependencies when using the 'cabal' binary, with
2 Typical breakages with GHC 6.10
54 new packages break with the current GHC 6.10 release candidate.
The primary reasons are:
- Changes to Arrow class definition
- Changes to Map monadic types
- Cabal changes
- Changes to ghc-api
- Changes to when 'forall' is parsed
- GHC.Prim was moved,
- Changes to -fvia-C and headers?
- GADT changes,
- pragma warnings tightened
- Integer constructors have moved
- New warnings and used -Werror
- Exception handling: catch, finally, throwIO don't work anymore
Each of these has a standard way to solve the problem. Techniques should be attached here.
2.1 Changes to Arrow class definition
The relevant change is essentially that Arrow became a superclass of Category. To be exact:
(>>>)was removed from Arrow, instead we have
idis a new function, in Category
What this means for code is that you need to declare an instance of Category as well as Arrow. A brute-force fix which should work:
- Add the following imports:
import Control.Category import Prelude hiding (id,(.)) -- conflicts with Category otherwise
instance Category [your type] wherefor any Arrows
- Move your
(>>>)definition into Category, and change
f >>> g = ...into
g . f = ...
idin Category. (Actually, I'm not 100% sure if this is strictly necessary for code that used to work in 6.8, but it's safest.)
And you're done.
3 Backwards compatibility
The new, suggested Cabal version range syntax,
is not backwards compatible with older versions of Cabal. Users will need to upgrade to the newer Cabal to build packages that start using this syntax.