Skip to content
  • Simon Peyton Jones's avatar
    [project @ 2005-04-28 10:09:41 by simonpj] · dd313897
    Simon Peyton Jones authored
    This big commit does several things at once (aeroplane hacking)
    which change the format of interface files.  
    
    	So you'll need to recompile your libraries!
    
    1. The "stupid theta" of a newtype declaration
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Retain the "stupid theta" in a newtype declaration.
    For some reason this was being discarded, and putting it
    back in meant changing TyCon and IfaceSyn slightly.
       
    
    2. Overlap flags travel with the instance
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Arrange that the ability to support overlap and incoherence
    is a property of the *instance declaration* rather than the
    module that imports the instance decl.  This allows a library
    writer to define overlapping instance decls without the
    library client having to know.  
    
    The implementation is that in an Instance we store the
    overlap flag, and preseve that across interface files
    
    
    3. Nuke the "instnce pool" and "rule pool"
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    A major tidy-up and simplification of the way that instances
    and rules are sucked in from interface files.  Up till now
    an instance decl has been held in a "pool" until its "gates" 
    (a set of Names) are in play, when the instance is typechecked
    and added to the InstEnv in the ExternalPackageState.  
    This is complicated and error-prone; it's easy to suck in 
    too few (and miss an instance) or too many (and thereby be
    forced to suck in its type constructors, etc).
    
    Now, as we load an instance from an interface files, we 
    put it straight in the InstEnv... but the Instance we put in
    the InstEnv has some Names (the "rough-match" names) that 
    can be used on lookup to say "this Instance can't match".
    The detailed dfun is only read lazily, and the rough-match
    thing meansn it is'nt poked on until it has a chance of
    being needed.
    
    This simply continues the successful idea for Ids, whereby
    they are loaded straightaway into the TypeEnv, but their
    TyThing is a lazy thunk, not poked on until the thing is looked
    up.
    
    Just the same idea applies to Rules.
    
    On the way, I made CoreRule and Instance into full-blown records
    with lots of info, with the same kind of key status as TyCon or 
    DataCon or Class.  And got rid of IdCoreRule altogether.   
    It's all much more solid and uniform, but it meant touching
    a *lot* of modules.
    
    
    4. Allow instance decls in hs-boot files
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Allowing instance decls in hs-boot files is jolly useful, becuase
    in a big mutually-recursive bunch of data types, you want to give
    the instances with the data type declarations.  To achieve this
    
    * The hs-boot file makes a provisional name for the dict-fun, something
      like $fx9.
    
    * When checking the "mother module", we check that the instance
      declarations line up (by type) and generate bindings for the 
      boot dfuns, such as
    	$fx9 = $f2
      where $f2 is the dfun generated by the mother module
    
    * In doing this I decided that it's cleaner to have DFunIds get their
      final External Name at birth.  To do that they need a stable OccName,
      so I have an integer-valued dfun-name-supply in the TcM monad.
      That keeps it simple.
    
    This feature is hardly tested yet.
    
    
    5. Tidy up tidying, and Iface file generation
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    main/TidyPgm now has two entry points:
    
      simpleTidyPgm is for hi-boot files, when typechecking only
      (not yet implemented), and potentially when compiling without -O.
      It ignores the bindings, and generates a nice small TypeEnv.
    
      optTidyPgm is the normal case: compiling with -O.  It generates a
      TypeEnv rich in IdInfo
    
    MkIface.mkIface now only generates a ModIface.  A separate
    procedure, MkIface.writeIfaceFile, writes the file out to disk.
    dd313897