GHCi recompilation avoidance UI

Ben Gamari ben at
Wed Nov 22 03:38:26 UTC 2017

David Feuer <david at> writes:

> 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?
It seems to me like the place to start would be occurrences of the
targetAllowObjCode field of Target.


- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <>

More information about the ghc-devs mailing list