Re: external core

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.