external core

[Josef Svenningsson]

Hi,

As Simon mentioned I am now responsible for external core. I have been
quite silent about it though since I took responsibility so I'll take
the opportunity to explain my plan and why it hasn't quite been
realised yet.

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 <john at repetae.net> 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.
> 
>         John
> 
> 
> --
> John Meacham - ⑆repetae.net⑆john⑈
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>