GHC Core output
Thu, 8 Feb 2001 20:26:06 -0800
I would *really* love to see GHC componetized (TM); it would even be better
if it would become easier to use the pieces. I would like to do experiments
on smaller bits of the compiler using Hugs (ideally the whole thing!). When
I was working on the Java/.NET backend I had to rebuild the whole compiler
just to test a few hundred lines of code that translated Core to Java which
is a major pain in the butt; I don't get a kick out of dealing with
installing Cygnus, recursive multi-staged makefiles, cpp, etc.
Erik "do you get a kick out of runnning the marathon with a ball and chain
at your feet?" Meijer
----- Original Message -----
From: "Andrew Tolmach" <email@example.com>
To: "'Timothy Docker'" <firstname.lastname@example.org>; <email@example.com>
Sent: Tuesday, February 06, 2001 2:53 AM
Subject: RE: GHC Core output
> 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
> useful points in the compilation sequence -- e.g., just before
> 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
> 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
> GHC-produced core
> (e.g., for the Prelude), and we don't aim to support this.
> Haskell-Cafe mailing list