2008-10-11 Hackage status with GHC 6.10

[Simon Peyton-Jones]

| So the next build with GHC 6.10 branch we should no longer see
| 'forall' parse failures from hackage libraries that use RULES?

Yes -- but not for the reasons below.  It should work now because I fixed http://hackage.haskell.org/trac/ghc/ticket/2497

Simon

| -----Original Message-----
| From: Don Stewart [mailto:dons at galois.com]
| Sent: 16 October 2008 19:40
| To: Simon Peyton-Jones
| Cc: Duncan Coutts; Henning Thielemann; libraries at haskell.org
| Subject: Re: 2008-10-11 Hackage status with GHC 6.10
|
| simonpj:
| > | RULES are always parsed (no flags or language extensions needed). They
| > | also go into the .hi files (unless you use the obscure option to change
| > | that), so they are exported for all client modules.
| >
| > The latter isn't true, and I think that's what Henning is objecting to.
| >
| > Currently, without -O GHC puts the absolute minimum in interface files
| > to get the clients to compile: just the exports and their types.  For
| > example, if you have
| >         f x = x
| > GHC will not put that unfolding in the interface file, tiny though it
| > is.
| >
| > Currently without -O GHC therefore does *not* put RULES in the
| > interface file.  I thought that was consistent, since they are to do
| > with optimisation.
| >
| > If, however, there's a consensus that RULES should be persisted even
| > without -O, that'd be easy to arrange. For example, I think that
| > deprecations are persisted unconditionally.
|
| So the next build with GHC 6.10 branch we should no longer see
| 'forall' parse failures from hackage libraries that use RULES?
|
| -- Don