GHC/Redesign: Difference between revisions
No edit summary |
No edit summary |
||
Line 48: | Line 48: | ||
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. | 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. | ||
Alternative interface: | Alternative interface (pretty much just random ideas for now): | ||
data HscTarget | data HscTarget | ||
= HscC | = HscC | ||
Line 54: | Line 54: | ||
| HscJava | | HscJava | ||
| HscILX | | HscILX | ||
compileToBytecode :: Session -> ModSummary -> IO | compileToBytecode :: Session -> ModSummary -> IO SuccessFlag | ||
compileToHardcode :: Session -> ModSummary -> | compileToHardcode :: Session -> ModSummary -> HscTarget -> IO SuccessFlag | ||
compileToNothing :: Session -> ModSummary -> IO | compileToNothing :: Session -> ModSummary -> IO SuccessFlag | ||
-- unload stable linkables, compile the files, don't link. | |||
batchBytecode :: Session -> [Target] -> IO SuccessFlag | batchBytecode :: Session -> [Target] -> IO SuccessFlag | ||
-- compile the files, link. | |||
batchHardcode :: Session -> [Target] -> | batchHardcode :: Session -> [Target] -> HscTarget -> IO SuccessFlag | ||
oneshotHardcode :: Session -> Target -> | |||
oneshotHardcode :: Session -> Target -> HscTarget -> IO SuccessFlag | |||
load :: Session - [Target] -> (ModSummary -> IO (Maybe | load :: Session - [Target] -> (ModSummary -> IO (Maybe | ||
== Clean up of temporary files == | |||
GHC is currently using a very ugly 'DriverPipeline.getOutputFilename' function for deciding the output file for a given phase. This is done ''while'' we're compiling instead of ''before'', and is causing complications throughout the module. | |||
If we separate the file preprocessing (cpp) from the driver pipeline, we can get a complete view of all the output files before we write them. This allows us to abstract the file handling out of the inner pipeline loop. |
Revision as of 04:05, 9 May 2006
This page is a draft.
Goals:
- 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.
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.
Compilation interface
Current 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) | |||
Byte code | |||
Nothing (type-check) |
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.
Alternative interface (pretty much just random ideas for now):
data HscTarget = HscC | HscAsm | HscJava | HscILX
compileToBytecode :: Session -> ModSummary -> IO SuccessFlag compileToHardcode :: Session -> ModSummary -> HscTarget -> IO SuccessFlag compileToNothing :: Session -> ModSummary -> IO SuccessFlag
-- unload stable linkables, compile the files, don't link. batchBytecode :: Session -> [Target] -> IO SuccessFlag
-- compile the files, link. batchHardcode :: Session -> [Target] -> HscTarget -> IO SuccessFlag
oneshotHardcode :: Session -> Target -> HscTarget -> IO SuccessFlag load :: Session - [Target] -> (ModSummary -> IO (Maybe
Clean up of temporary files
GHC is currently using a very ugly 'DriverPipeline.getOutputFilename' function for deciding the output file for a given phase. This is done while we're compiling instead of before, and is causing complications throughout the module. If we separate the file preprocessing (cpp) from the driver pipeline, we can get a complete view of all the output files before we write them. This allows us to abstract the file handling out of the inner pipeline loop.