Excessive numbers of packages loaded for TH

When using Template Haskell, the behaviour of ghc with regard to loading packages differs in these two cases:

ghc --make Blah.hs

vs

ghc --make Blah.hs -package foo

In the first case, ghc will work out for itself which packages it needs to load to run the TH code in Blah.hs while in the second case, ghc will unconditionally load package foo in addition to anything else.

Why is this a problem? Consider a real example (reported on IRC):

ghc --make Main.hs
[1 of 4] Compiling Uplink           ( Uplink.hs, Uplink.o )
[2 of 4] Compiling FlightData       ( FlightData.hs, FlightData.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[3 of 4] Compiling Joystick         ( Joystick.hs, Joystick.o )
[4 of 4] Compiling Main             ( Main.hs, Main.o )
 
Linking Main.exe ...

This just loads base and its deps. Great, it works.

Now the exact same Main.hs built by cabal (which of course uses -package-id flags):

cabal build
Building jpl-0.1.0.0...
Preprocessing executable 'jpl' for jpl-0.1.0.0...
[1 of 4] Compiling Uplink           ( Uplink.hs, dist\build\jpl\jpl-tmp\Uplink.o )
[2 of 4] Compiling FlightData       ( FlightData.hs, dist\build\jpl\jpl-tmp\FlightData.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package binary-0.7.1.0 ... linking ... done.
Loading package SHA-1.6.4.2 ... linking ... done.
Loading package text-1.2.0.4 ... linking ... done.

1. .. snip a further 80, yes 80 packages ...

Loading package linear-1.18.0.1 ... linking ... done.
Loading package sdl2-2.0.0 ... linking ... ghc.exe: unable to load package `sdl2-2.0.0'
ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup
ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup
ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup

1. .. snip more boring details of the linker errors ...

So yes the problem is that in practice some packages (typically FFI things) just can't be loaded in GHCi/TH and then this scuppers everything else, despite the fact that these packages never needed to be loaded in the first place.

So the feature request is this: always use the parsimonious demand-driven algorithm for deciding what packages to load when running TH snippets, and don't consider -package flags to be instructions to load these packages for running TH code.

As a bonus it'll be quicker and our build output shorter.

Trac metadata

Trac field	Value
Version	7.10.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture