<div dir="ltr"><div><div><div>David,<br><br></div>Perhaps it would be good to defer changing the behaviour of :load *M (I believe you that it's hard, that code is quite convoluted) and for now just focus on making GHCi able to load compiled object code again, which I think is a much simpler problem?<br><br></div>Cheers<br></div>Simon<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 21 November 2017 at 21:49, David Feuer <span dir="ltr"><<a href="mailto:david@well-typed.com" target="_blank">david@well-typed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I started digging back into this today, particularly considering Simon PJ's view<br>
that it's a bit odd for optimization flags to imply -fobject-code (specifically<br>
because we could potentially support optimization for the bytecode<br>
interpreter some day). I'm left even more lost about exactly what we want.<br>
I believe it's fairly clear that, as Simon M wrote,<br>
<br>
> [W]e'll want at least -fignore-optim-changes to be the default, so that GHCi<br>
<span class="">> does the expected thing when you have compiled object files.<br>
<br>
</span>Based on Simon PJ's comment, I believe we want to *continue* to discard<br>
optimization flags when -fobject-code is not enabled. As for my suggestion in (2),<br>
I spent the last couple hours attempting to figure out what would be necessary<br>
to allow :load *M to load a module  interpreted even when using -fobject-code,<br>
but found myself utterly lost in the module loading logic. I see that the IIModule<br>
constructor is deeply involved in this, but I haven't been able to figure out<br>
where/how that interacts with -fobject-code to determine whether the module<br>
will actually be loaded interpreted or compiled. Can someone give me a clue?<br>
<div class="HOEnZb"><div class="h5"><br>
On Thursday, November 2, 2017 10:21:07 AM EST Simon Marlow wrote:<br>
> On 31 October 2017 at 15:42, David Feuer <<a href="mailto:david@well-typed.com">david@well-typed.com</a>> wrote:<br>
><br>
> > Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now<br>
> > refuses to load optimized<br>
> > code unless -fobject-code (and optimization flags) are enabled. I propose<br>
> > the following slight<br>
> > modification to <a href="https://ghc.haskell.org/trac/ghc/ticket/13604#comment:48" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/ticket/13604#comment:48</a><br>
> ><br>
> > 1. Optimization flags (except -O0) imply -fobject-code. This ensures that<br>
> > GHC respects optimization flags regardless of --interactive.<br>
> ><br>
> > 2. Even when -fobject-code is on, :load *M will load M as bytecode. This<br>
> > provides the "escape hatch" from -fobject-code that you need to use<br>
> > debugging features, etc.<br>
> ><br>
><br>
> Yes, I think this is probably what we want. I'm not sure how smooth it will<br>
> be to implement though.<br>
><br>
><br>
> > 3. New -fignore-optim-changes and -fignore-hpc-changes (​​Phab:D4123)<br>
> > flags should enable users to put together object code and bytecode with<br>
> > diverse optimization levels/options and HPC options while still updating<br>
> > automatically based on source changes and whether profiling is enabled.<br>
> ><br>
><br>
> As I mentioned on the diff, I think we'll want at least<br>
> -fignore-optim-changes to be the default, so that GHCi does the expected<br>
> thing when you have compiled object files.<br>
><br>
> Cheers<br>
> Simon<br>
</div></div></blockquote></div><br></div>