Changes between Version 10 and Version 11 of GhcApiStatus


Ignore:
Timestamp:
May 27, 2008 11:28:34 AM (6 years ago)
Author:
simonmar
Comment:

add refactoring ideas

Legend:

Unmodified
Added
Removed
Modified
  • GhcApiStatus

    v10 v11  
    6767 * ... more comments here ... 
    6868  
     69== Refactoring Ideas == 
     70 
     71There follow some notes about desirable refactorings, mainly around [[GhcFile(compiler/main/HscMain.lhs)]].  These will be important when looking at how to modify the GHC API to expose the individual compilation stages.  At the moment, the compilation stages are all hidden behind the `HscMain` interface, which in turn is hidden behind the `DriverPipeline` module, which is used by the code in `GHC`.  In order to untangle things, we need to make some changes.  Not all of these are essential, and some of them might not even end up being good ideas at all; this is just a list of things we (Simon M & Simon PJ) noticed while doing a code walkthrough. 
     72 
     73 * We should separate the action of reading the old interface from checking its usages.  Currently the two 
     74   are mixed up in `checkOldIface`.  (in the new story with fingerprints instead of versions, we also want 
     75   to discard the old interface as soon as we decide to recompile, because it isn't necessary for calculating 
     76   the new versions now). 
     77 
     78 * Perhaps `HsModule` should indicate whether the module is an `hs-boot` module or not.  That would reduce the 
     79   number of arguments to `tcRnModule` by one. 
     80 
     81 * It would be nicer to return error messages from each phase directly rather than invoking the `log_action` callback 
     82   in `DynFlags`. 
     83 
     84 * What is currently called `RenamedStuff` should be `HsModule Name`.  Hence, the `tcg_rn_` files in `TcGblEnv` 
     85   can be merged into a single `tc_rn_module`. 
     86 
     87 * instead of passing a `Bool` to `tcRnModule` to ask for the renamed syntax, use a flag in `DynFlags`? 
     88 
     89 * `mi_globals` is in the wrong place: it is not part of the interface.  The reason it is where it is is because 
     90   we need to keep it when a module is considered for compilation but not recompiled; when we generate the 
     91   `ModDetails` from the `ModIface`.  ToDo: find a better place to put it.