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.
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"
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
participants (2)
-
Andrew Tolmach -
Erik Meijer