Making (useful subsets of) bytecode portable between targets

Edward Z. Yang ezyang at
Fri Nov 25 15:45:52 UTC 2016

Excerpts from Shea Levy's message of 2016-11-25 10:30:25 -0500:
> > The right thing is to have a clean separation between runtime
> > imports and compile-time imports.  Perhaps we just annotate some imports to
> > say they aren't needed at compile-time for running the TH code.  but then
> > we also need compile-time vs. runtime build-depends in our .cabal files,
> > and so on.
> Yes, I was just looking into this yesterday. We already have something
> similar for plugins, though of course the TH story is much more
> involved (in part because GHC has to compile haskell code, not just load
> and run a pre-existing object file).

Actually, we don't really have this for plugins either. It is true that
you can load a plugin independently of the imports of the module it is
compiling, and that you can setup an independent package database for
plugins, but the interfaces of the plugin are still all dumped in
the same interface database that GHC uses for compile-time interfaces
as well.  It's delicate and has caused bugs before (


More information about the ghc-devs mailing list