GHCi recompilation avoidance UI

[Evan Laforge]

On Wed, Nov 1, 2017 at 1:46 AM, Simon Peyton Jones via ghc-devs
<ghc-devs at haskell.org> wrote:
> I'm lost.
>
> * What causes the undesired behaviour in GHC 8.2.1?
>   Is it this?
>     - GHCi wants to load module B with flags F
>     - There is a B.o but the flags differ
>     - So GHCi recompiles B to bytecode
>
> * How does (1) help?

>From my perspective, what happened is that GHC 8.2 started including
the -O and -fhpc flags in the hash for recompilation avoidance, so
it's started to notice when those particular flags differ.  However,
ghci has always rejected those two flags, courtesy of
DynFlags.makeDynFlagsConsistent.  The result is that it's now
impossible for ghci to load modules compiled with those flags, since
it will never have the right flags.  The reason that's a problem is
that it's really convenient to run tests (compiled with -fhpc)
interactively, and use the GHC API to interpret code when the rest of
the system is compiled with -O.  That latter usage might be on thin
ice according to the comment on makeDynFlagsConsistent, but in
practice it's worked fine for a long time.

I'll let David answer about how #1 helps, but it looks like maybe ghci
could have supported -O just fine with -fobject-code, so it should
have been using that to determine whether or not to reject -O, not
--interactive.

> * Does (2) propose a new command (:load *M vs :load M)?
>   If so, how does it help.

:load *M has always been present, so I'm not sure what is the
difference.  Maybe it didn't override -fobject-code before.  I'll let
David answer this and #3.

But I think the effect of the flags in #3 would be "go back to <8.2",
which is to say, omit -O and -fhpc from the interface hash.  So yes, I
think your description sounds right.