external core

[Robin Bate Boerop]

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 <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.