[GHC] #10419: Refactor LoadIface to distinguish getting a ModIface versus loading into EPT

GHC ghc-devs at haskell.org
Fri May 15 08:48:31 UTC 2015


#10419: Refactor LoadIface to distinguish getting a ModIface versus loading into
EPT
-------------------------------------+-------------------------------------
        Reporter:  ezyang            |                   Owner:  ezyang
            Type:  task              |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler (Type    |                 Version:  7.11
  checker)                           |                Keywords:
      Resolution:                    |            Architecture:
Operating System:  Unknown/Multiple  |  Unknown/Multiple
 Type of failure:  None/Unknown      |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Hmm.  Note that
  * If you want a declaration you have to load the `ModIface`, and we don't
 want to do that twice, so D implies I.
  * If you want the `ModIface` it's not much work to load all the
 declarations because we typecheck them lazily (via `forkM` in `TcIface`).
 So it's not clear to me that you are going to save much work.

 So: what's your goal here?  Just efficiency?

 The proposal would mean that in the `ExternalPackageState` there might be
 members of the `eps_PIT` whose declarations have not been typechecked and
 loaded into the `eps_PTE`.  Currently it's an invariant that they all are.
 That might be fine but it needs documenting.  Here just for reference is
 the current defn of EPS:
 {{{
 data ExternalPackageState
   = EPS {
         eps_is_boot      :: !(ModuleNameEnv (ModuleName,
 IsBootInterface)),
         eps_PIT          :: !PackageIfaceTable,
         eps_PTE          :: !PackageTypeEnv,
         eps_inst_env     :: !PackageInstEnv,
         eps_fam_inst_env :: !PackageFamInstEnv,
         eps_rule_base    :: !PackageRuleBase,
         eps_vect_info    :: !PackageVectInfo,
         eps_ann_env      :: !PackageAnnEnv,
         eps_mod_fam_inst_env :: !(ModuleEnv FamInstEnv),
         eps_stats :: !EpsStats
   }
 }}}

 Thinking about the invariant leads to some questions:

  * Consider a module whose `ModIface` M we have loaded, into the
 `eps_PIT`.  Now suppose we want the declaration for `M.foo`.  Do
 we:[[BR]][[BR]]
    1. Find `foo`'s `IfaceDecl` in M's `ModIface` and add that declaration
 alone to `eps_PTE`?  But how do we find `foo`'s `IfaceDecl`, remembering
 that one `IfaceDecl` may bind many `Name`s.?  You'll need to build a
 little index; but that is (in effect) what the `eps_PTE` already is!
 [[BR]][[BR]]
    2. Typecheck all the declarations in M's `ModIface` and add all of them
 to the `eps_PTE`?  If so, how do we record that we have done this so we
 don't repeat it?  Maybe it's enough that future lookups will find `M.foo`
 in the PTE.

  * Currently we assume that if we've loaded an interface for a non-orphan
 module we've loaded its instances into `eps_inst_env`. But that won't be
 true any more.  Or will it?

  * Similarly we'd have to think about `eps_ann_env`,
 `eps_mod_fam_inst_env` etc.

 So currently I'm unconvinced.

 Simon

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10419#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list