Now we have forked the tree
- we can make Applicative a superclass of Monad
- and remove all the AMP warning stuff
That should resolve this particular issue, shouldn't it?
Austin, would you like to go ahead and do that?
Simon
| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Simon
| Marlow
| Sent: 18 April 2014 21:32
| To: Austin Seipp
| Cc: ghc-devs@haskell.org
| Subject: Re: Heap usage of GHC increased in 7.8 vs. 7.6
|
| On 18/04/14 20:42, Austin Seipp wrote:
| > Yes, you're right regarding the AMP patches. Concerning this, I looked
| > the patch back up to refresh my memory, and there reason we do this
| > was because we need to check (and warn) if there are locally defined
| > names in the current module which would clash with names from the
| > Applicative-Monad proposal, among others - notably, naming functions
| > like 'join' or whatnot in the current scope clashes. This means we
| > wire in the 'Name's for join, <*>, etc from Control.Applicative and
| > Control.Monad so we can check against them later, which implies
| > loading the interfaces I believe.
| >
| > Perhaps we don't even need a wired Name for this particular step,
| > which would sidestep that issue.
| >
| > But thinking about it - even fixing that, is this even avoidable,
| > ultimately? The AMP warnings in 7.8 are actually temporary, and will
| > be gone from HEAD soon. But once we do that and AMP is actually
| > *implemented* in base, won't it essentially imply the loading of these
| > same interfaces by default, and thus about the same amount of memory
| > use?
|
| I don't think it will. Except for orphan modules, interfaces are
| normally only loaded when we actually use something defined in that
| module.
|
| Perhaps this isn't a huge deal since it's a small fixed overhead, but it
| bugs me nonetheless.
|
| Cheers,
| Simon
|
|
| > Or is there a planned module refactoring/shuffling too, since we're
| > already breaking some user code this cycle? If there is, maybe this
| > won't be problematic in the end or we should revisit it when the
| > numbers are solid. I honestly don't know what all the expected
| > intra-module changes might be (I've CC'd Edward in case he'd like to
| > chime in about that.)
| >
| >
| > On Fri, Apr 18, 2014 at 10:39 AM, Simon Marlow