On Fri, Jun 8, 2018 at 11:46 AM, Simon Marlow
I'm slightly surprised that it keeps breaking for you, given that this is a core feature of GHCi and we have multiple tests for it. You'll need to remind me - what were the bugs specifically? Maybe we need more tests.
Most recently, 8.2 had this problem: https://ghc.haskell.org/trac/ghc/ticket/13604 I seem to recall an older version also had the same problem, in that it was too sensitive about hash changes, but I think it was a plain bug, unlike the ticket above which is arguable correct though inconvenient. I also remember requesting the "why did it reload" message (e.g. flags changed, etc.), probably due to some earlier change that made compiled modules not load. It's been so long I forget the details, sorry! Currently -fdefer-type-errors is broken: https://ghc.haskell.org/trac/ghc/ticket/14963 This is not related to loading .o files, but ghci in general. Also currently there's an issue where ghc uses modtime and then the elaborate recompilation check to determine whether to recompile to binary, but it seems ghci uses just the modtime check. I think this has always been there, but I'm only just noticing it recently because of switching to git. I don't completely understand what's going on here yet so I may be misrepresenting the situation. More tests would be welcome! I guess we could compile some modules, and ensure the binary continues to load after various kinds of poking and prodding. I'd be willing to contribute tests that represent my workflow.
There really are fundamental differences in how the compiler treats these two methods though, and I don't see an easy way to reconcile them. Loading object files happens as part of the compilation manager that manages the compilations for all the modules in the current package, whereas packages are assumed to be pre-compiled and are linked on-demand after all the compilation is done.
Ah, too bad. But just out of curiosity, is there anything about the OS level linking that's fundamentally different than ghci loading individual .o files, or is this more a result of how ghc and ghci have evolved? I know you did some work to unload object files, could the same thing be used to unload and reload packages dynamically? Even if it were manual, it could be a big improvement over having to shut down and restart the whole system because a package changed.