#7619: Make worker-wrapper unbox data families -------------------------------------+------------------------------------ Reporter: akio | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: type family Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): This is actually simple to implement (see [a1ddb71/ghc] on branch `wip/T7619`), but rather ugly due to the additional passing of the FamInstEnv everywhere. That’s why I did not push to master yet. There are types `FamInstEnvs` and `FamInstEnv`, but it is not well- explained, only {{{ type FamInstEnvs = (FamInstEnv, FamInstEnv) -- External package inst-env, Home-package inst-env }}} Note that `topNormaliseType_maybe` takes a `FamInstEnvs`, and I can get a `FamInstEnv` from the `ModGuts` and from `ExternalPackageState`. If I combine these as follows, am I doing the right thing? {{{ doPassDFU :: (DynFlags -> FamInstEnvs -> UniqSupply -> CoreProgram -> CoreProgram) -> ModGuts -> CoreM ModGuts doPassDFU do_pass guts = do dflags <- getDynFlags us <- getUniqueSupplyM hsc_env <- getHscEnv eps <- liftIO $ hscEPS hsc_env let fam_envs = (eps_fam_inst_env eps, mg_fam_inst_env guts) doPass (do_pass dflags fam_envs us) guts }}} And why do we need to make that distinction in the first place – it seems that `topNormaliseType_maybe` does not treat them differently. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7619#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler