GHC Core output
Tue, 6 Feb 2001 02:53:55 -0800
Timothy Docker [mailto:firstname.lastname@example.org] writes:
> > We agreed that it would be a Jolly Good Thing if GHC could
> > be persuaded to produce GHC-independent Core output,
> > ready to feed into some other compiler. For example,
> > Karl-Filip might be able to use it.
> > ANDREW will write a specification, and implement it.
> A quick question. What is meant by "Core output"? Subsequent posts
> seem to suggest this is some "reduced Haskell", in which full Haskell
> 98 can be expressed. Am I completely off beam here?
Not at all.
"Core" is an intermediate language used internally by the GHC compiler.
It does indeed resemble a reduced Haskell (but with explicit higher-order
polymorphic types) and GHC translates full Haskell 98 into it.
Currently Core has no rigorously defined external representation, although
by setting certain compiler flags, one can get a (rather ad-hoc) textual
representation to be printed at various points in the compilation process.
(This is usually done to help debug the compiler).
What we hope to do is:
- provide a formal definition of Core's external syntax;
- give a precise definition of its semantics (both static and dynamic);
- modify GHC to produce external Core files, if so requested, at one or more
useful points in the compilation sequence -- e.g., just before optimization,
or just after.
- modify GHC to accept external Core files in place of Haskell
source files, again at one or more useful points.
The first three facilities will let one couple GHC's front-end (parser,
type-checker, etc.), and optionally its optimizer, with new back-end tools.
Adding the last facility will let one implement new Core-to-Core
transformations in an external tool and integrate them into GHC. It will
allow new front-ends to generate Core that can be fed into GHC's optimizer
back end; however, because there are many (undocumented)
idiosynracies in the way GHC produces Core from source Haskell, it will be
for an external tool to produce Core that can be integrated with
(e.g., for the Prelude), and we don't aim to support this.