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,
> On 7/27/05, John Meacham <[hidden email]> wrote:
>> Now, the external core feature of ghc is great, but it is not
>> 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/
>> 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
>> 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
>> to be separated and cabalized. I know there was talk of creating a
>> internals library, but it would be nice if this code were portable