Re: GHCi recompilation avoidance UI

I started digging back into this today, particularly considering Simon PJ's view that it's a bit odd for optimization flags to imply -fobject-code (specifically because we could potentially support optimization for the bytecode interpreter some day). I'm left even more lost about exactly what we want. I believe it's fairly clear that, as Simon M wrote,

[W]e'll want at least -fignore-optim-changes to be the default, so that GHCi does the expected thing when you have compiled object files.

Based on Simon PJ's comment, I believe we want to *continue* to discard optimization flags when -fobject-code is not enabled. As for my suggestion in (2), I spent the last couple hours attempting to figure out what would be necessary to allow :load *M to load a module interpreted even when using -fobject-code, but found myself utterly lost in the module loading logic. I see that the IIModule constructor is deeply involved in this, but I haven't been able to figure out where/how that interacts with -fobject-code to determine whether the module will actually be loaded interpreted or compiled. Can someone give me a clue? On Thursday, November 2, 2017 10:21:07 AM EST Simon Marlow wrote:

On 31 October 2017 at 15:42, David Feuer wrote:

...

Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now refuses to load optimized code unless -fobject-code (and optimization flags) are enabled. I propose the following slight modification to https://ghc.haskell.org/trac/ghc/ticket/13604#comment:48

1. Optimization flags (except -O0) imply -fobject-code. This ensures that GHC respects optimization flags regardless of --interactive.

2. Even when -fobject-code is on, :load *M will load M as bytecode. This provides the "escape hatch" from -fobject-code that you need to use debugging features, etc.

Yes, I think this is probably what we want. I'm not sure how smooth it will be to implement though.

...

3. New -fignore-optim-changes and -fignore-hpc-changes (​​Phab:D4123) flags should enable users to put together object code and bytecode with diverse optimization levels/options and HPC options while still updating automatically based on source changes and whether profiling is enabled.

As I mentioned on the diff, I think we'll want at least -fignore-optim-changes to be the default, so that GHCi does the expected thing when you have compiled object files.

Cheers Simon