GHC Core output

[Erik Meijer]

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" <t-atolm@microsoft.com>
To: "'Timothy Docker'" <timd@macquarie.com.au>; <haskell-cafe@haskell.org>
Sent: Tuesday, February 06, 2001 2:53 AM
Subject: RE: GHC Core output


> Timothy Docker [mailto:timd@macquarie.com.au] 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
> also
> allow new front-ends to generate Core that can be fed into GHC's optimizer
> or
> back end; however, because there are many (undocumented)
> idiosynracies in the way GHC produces Core from source Haskell, it will be
> hard
> 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
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe