Opened 10 years ago

Closed 10 years ago

#3560 closed bug (duplicate)

Template Haskell attempts to load unnecessary packages

Reported by: heatsink Owned by:
Priority: normal Milestone:
Component: Template Haskell Version: 6.10.4
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

To run TH splices, GHC's interpreter loads all packages specified on the command line, even if they are not needed. This causes compilation to fail when an unused package works with the compiler, but not with the interpreter.

Consider the one-line program {-# LANGUAGE TemplateHaskell #-} main = print $([|1|]). I can compile it with ghc --make Main.hs. If I add the extra command line parameter -package WeakTest, compilation fails when attempting to load the WeakTest package. (This package demonstrates a GHCi bug and is attached to #3333).

Why put a superfluous package on the command line? This may happen because a build system uses the same set of flags to compile every file. This is the current behavior of Cabal.

A possible solution would be for GHC to reuse the mechanism that GHC --make uses for deciding which command line packages to actually load. This way, extra packages won't prevent compilation. This would make it easier to use TH in a project that relies on non-interpreted packages.

See also #3333. Possibly related #2555.

Change History (2)

comment:1 Changed 10 years ago by duncan

I should note that this would also improve the compile times in large projects that use TH. For example, in a happstack server a little bit of TH in one module ends up loading about 40 packages. The TH/ghci package load time is what actually dominates.

That said, this performance problem will also go away if we use shared libs.

comment:2 Changed 10 years ago by simonmar

difficulty: Unknown
Resolution: duplicate
Status: newclosed

This is a dup of #2437, but I forgive you for not finding it, it took me quite a bit of searching to track the ticket down. Using the actual dependencies is a good idea, so I'll point to this ticket from #2437.

Note: See TracTickets for help on using tickets.