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⑈

I am interested in this. Has there been any progress? -- Robin Bate Boerop On 28-Jul-05, at 7:46 AM, Josef Svenningsson wrote:

The plan was, just as John suggest, to produce a library with various external core functionality. GHC would then import this package to parse and produce external core. That way we would have a single source of all external core code that programmers could easily use. I started working on this but it slid down my priority list. The reason was that I got almost no replies when I asked for interest in external core on the ghc-users list. The plan was however to have an initial version of the library done in the beginning of June. The reasons that this hasn't been realised are various and has also resulted in that I am currently on sick-leave and rather incapacitated. I cannot promise any progress at the moment. But I'd be happy to discuss the library and accept code from anyone who is willing to work on it.

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 :-)

All the best,

/Josef

On 7/27/05, John Meacham wrote:

...

Now, the external core feature of ghc is great, but it is not utilized very much. The main reason I think is that there is a large barrier to entry in writing something that uses it since you need to parse/ generate it.

It would be nice if there were a standard library that came with ghc (or cabalized and portable even better) that could parse and pretty print external core.

ideally, one could write a simple pass-through core processor that interacts with ghc in a single line and someone working on a new optimization need only worry about that.

Also, it would make it very easy for jhc to generate and parse ghc core files (always an ulterior motive). I wanted to use jhcs front end to generate ghc core so I could get a true measure of the difference in just their back-end performance without taking into account ghc's superior high-level optimizations.

In any case. I think all the code is out there in ghc and it just needs to be separated and cabalized. I know there was talk of creating a ghc internals library, but it would be nice if this code were portable and independent.