Thanks. I have written a blog post to describe the generalisation question and describe how to adapt your code http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 I've added the link to Don's GHC7 page. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Don Stewart | Sent: 29 September 2010 14:53 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org | Subject: Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1 | | I've created a wiki page to track the common errors when upgrading to | GHC 7. | | http://haskell.org/haskellwiki/Upgrading_packages/Updating_to_GHC_7 | | Solutions to each problem should be listed here. | | simonpj: | > I've been meaning to write a blog post about this, because it's a significant change. | I'll do this when I get home after ICFP. Briefly though: | > | > * If you use -XGADTs or -XTypeFamilies (or -fglasgow-exts, which is deprecated) | you get -XMonoLocalBinds, which says that local let/where bindings are not auto- | generalised. There's an extensive discussion of the reason for this decision in our | paper "Let should not be generalised" and the journal version | http://haskell.org/haskellwiki/Simonpj/Talk:OutsideIn | > | > * One of the main times this matters is in situations like | > foo = runST (bar 5) | > where bar x = return x | > Here 'bar' must have a polymorphic type, in order to be mentioned in runST's | argument | > | > * The error message does point out that 'bar' is a possible culprit. In David's | example: | > The following variables have types that mention s | > fill0 :: MBUArr s e -> ST s Int | > | > * The solution is usually to add a type signature for the offending variable (fillO in | this case); you can still have polymorphic bindings in let/where, but they need a type | signature. | > | > Simon | > | > | -----Original Message----- | > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | > | bounces@haskell.org] On Behalf Of David Fox | > | Sent: 29 September 2010 04:11 | > | To: glasgow-haskell-users@haskell.org | > | Subject: Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1 | > | | > | I'm seeing errors like this in various places, which I guess are | > | coming from the new type checker: | > | | > | Data/Array/Vector/Prim/BUArr.hs:663:3: | > | Couldn't match type `s' with `s3' | > | because this skolem type variable would escape: `s3' | > | This skolem is bound by the polymorphic type `forall s. ST s a' | > | The following variables have types that mention s | > | fill0 :: MBUArr s e -> ST s Int | > | (bound at Data/Array/Vector/Prim/BUArr.hs:669:5) | > | In the first argument of `runST', namely | > | `(do { marr <- newMBU n; | > | n' <- fill0 marr; | > | unsafeFreezeMBU marr n' })' | > | | > | I would love to hear an explanation about what they mean and what to | > | do about them. (This one is from uvector.) | > | _______________________________________________ | > | Glasgow-haskell-users mailing list | > | Glasgow-haskell-users@haskell.org | > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users