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
