Here's some useful background from Lemmih about what he's up to. Simon
-----Original Message----- From: Lemmih [mailto:[EMAIL PROTECTED] Sent: 06 March 2006 14:13 To: Simon Peyton-Jones Subject: Re: patch applied (ghc): Remove the old HscMain code. On 3/6/06, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: > Hi Lemih > > Again, could you give a brief overview of this sequence of patches? > We're delighted you are working on the GHC interface. Brief overview: I've changed "hscMain :: [inputargs] -> IO HscResult" to: * hscCompileOneShot :: [inputargs] -> IO (Maybe HscStatus) * hscCompileMake :: [inputargs] -> IO (Maybe (HscStatus, ModIface, ModDetails)) * hscCompileInteractive :: [inputargs] -> IO (Maybe (InteractiveStatus, ModIface, ModDetails)) This means that we don't have to return _|_ for ModIface and ModDetails in one-shot mode and we don't have to return (Nothing :: Maybe CompiledByteCode) in make/batch mode. The internals are also smarter now; compiling to nothing (JustTypecheck) is a bit faster since it avoids some simplification. I'm working on completely avoiding the simplifier when compiling to nothing. Longish description of what I've done and what I intend to do: This is the comment from my first patch: [comment] The current Haskell compiler (HscMain.hscMain) isn't as typed and as hack-free as we'd like. Here's a list of the things it does wrong: * In one shot mode, it returns the new interface as _|_, when recompilation isn't required. It's then up to the users of hscMain to keep their hands off the result. * (Maybe ModIface) is passed around when it's known that it's a Just. Hey, we got a type-system, let's use it. * In one shot mode, the backend is returning _|_ for the new interface. This is done to prevent space leaks since we know that the result of a one shot compilation is never used. Again, it's up to the users of hscMain to keep their hands off the result. * It is allowed to compile a hs-boot file to bytecode even though that doesn't make sense (it always returns Nothing::Maybe CompiledByteCode). * Logic and grunt work is completely mixed. The frontend and backend keeps checking what kind of input they're handling. This makes it very hard to get an idea of what the functions actually do. * Extra work is performed when using a null code generator. The new code refactors out the frontends (Haskell, Core), the backends (Haskell, boot) and the code generators (one-shot, make, nothing, interactive) and allows them to be combined in typesafe ways. A one-shot compilation doesn't return new interfaces at all so we don't need the _|_ space-leak hack. In 'make' mode (when not targeting bytecode) the result doesn't contain Nothing::Maybe CompiledByteCode. In interactive mode, the result is always a CompiledByteCode. The code gens are completely separate so compiling to Nothing doesn't perform any extra work. [/comment] And I've written this at the top of HscMain: [HscMain] -------------------------------- The compilation proper -------------------------------- It's the task of the compilation proper to compile Haskell, hs-boot and core files to either byte-code, hard-code (C, asm, Java, ect) or to nothing at all (the module is still parsed and type-checked. This feature is mostly used by IDE's and the likes). Compilation can happen in either 'one-shot', 'make', or 'interactive' mode. 'One-shot' mode targets hard-code, 'make' mode targets hard-code and nothing, and 'interactive' mode targets byte-code. The modes are kept separate because of their different types. In 'one-shot' mode, we're only compiling a single file and can therefore discard the new ModIface and ModDetails. This is also the reason it only targets hard-code; compiling to byte-code or nothing doesn't make sense when we discard the result. 'Make' mode is like 'one-shot' except that we keep the resulting ModIface and ModDetails. 'Make' mode doesn't target byte-code since that require us to return the newly compiled byte-code. 'Interactive' mode is similar to 'make' mode except that we return the compiled byte-code together with the ModIface and ModDetails. Trying to compile a hs-boot file to byte-code will result in a run-time error. This is the only thing that isn't caught by the type-system. [/HscMain] However, the code isn't finished yet. I'm gonna introduce another step for outputting the interface and external core. This will remove the need to consult GhcMode in writeIfaceFile: When we're compiling to nothing (JustTypecheck) or byte-code, writeIfaceFile simply wont be called. My long term goal is to remove all references to GhcMode and HscTarget. They're causing GHC to be written in a dynamically typed way (see, for example, the run-time type-checks in the old HscMain code). -- Friendly, Lemmih _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
