On Thu, Jul 28, 2005 at 01:46:41PM +0200, Josef Svenningsson wrote:
John, could you elaborate on suggestion of having a "pass-through core processor that interacts with ghc". I'm not quite sure I understand what you're after. But it sounds interesting :-)
Ideally, this is what I would like from ghc and a library (some of this already exists). ghc should have the options --input-core - take hcr files as input and compile them as normal --output-core - spit out hcr files instead of generating code note that with these two, you have access to just ghc's optimizer by using both of them. now the fun one is --passes --passes cpranalysis,ext=./myopt,strictness,ext=./myopt2,fullylazy basically, this just defines the transformations ghc is to use. the interesting new bit is 'ext=<program>' which is a program that simply takes ghc core on stdin and spits out core on stdout. this allows easy adding of custom passes to ghc. so, with all these features you can (easily, simply) - write custom optimization passes - use just ghc's front end - use just ghc's back end - play with the order of passes - use ghc's optimizer as a plugin for a different compiler that speaks core now out of the library: module Core where -- type defining core syntax, probably similar (but simpler) to the one in ghc data Core = .... -- parse core, in a monad for reporting errors parseCore :: Monad m => String -> m Core parseCore = ... -- print core printCore :: Core -> String printCore = ... this will allow you to write custom optimization passes really easily: main = getContents >>= putStr . printCore . customPass . parseCore -- your optimization customPass :: Core -> Core customPass = ... the functions would also be useful when using just ghc's front or back end. John -- John Meacham - ⑆repetae.net⑆john⑈