This page is a draft.
- Separate the GHC specific logic from the library.
- Make better use of the type-system! A lot of GHC is written as if Haskell were dynamically typed.
- Cut down on global mutable variables.
1 Global mutable variables
- SysTools.v_FilesToClean of type [String].
- List of temporary files to remove. May contain wildcards [used by DriverPipeline.run_phase SplitMangle].
The other global mutable variables have to do with the linker, initDynFlags, ways and static flags.
2 Compilation interface
data LoadHowMuch = LoadAllTargets | LoadUpTo Module | LoadDependenciesOf Module -- 'hscTarget' and 'ghcMode' governs the exact behaviour. load :: Session -> LoadHowMuch -> IO SuccessFlag
However, there're many invalid combinations of 'hscTarget' and 'ghcMode'.
|hscTarget \ ghcMode||Batch||OneShot||Interactive|
|Hard code (C,asm,etc)||
For example, if you set 'ghcMode' to Interactive without changing 'hscTarget' from its 'HscC' default, ghc will try to run 'gcc' on a non-existing file. I'd like to describe the behaviour of 'load' via function composition instead of mutable flags. Moreover, I'd like to remove the targets, module graph and interactive context from the HscEnv.
data HscTarget = HscC | HscAsm | HscJava | HscILX -- FIXME: We need delete temporary files after compilations. compileToBytecode :: Session -> ModSummary -> IO a -> IO (Maybe a) compileToHardcode :: Session -> ModSummary -> HardcodeTarget -> IO a -> IO (Maybe a) compileToNothing :: Session -> ModSummary -> IO a -> IO (Maybe a) batchBytecode :: Session -> [Target] -> IO SuccessFlag batchBytecode session targets = do deps <- depanal session targets foldr (\mod fn lst -> batchHardcode :: Session -> [Target] -> HardcodeTarget -> IO SuccessFlag oneshotHardcode :: Session -> Target -> HardcodeTarget -> IO SuccessFlag load :: Session - [Target] -> (ModSummary -> IO (Maybe