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-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@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-boun...@haskell.org
[mailto:glasgow-haskell-users-
| > | boun...@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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
