7
votes

I would like to create a frontend for a simple language that would produce GHC Core. I would like to then take this output and run it through the normal GHC pipeline. According to this page, it is not directly possible from the ghc command. I am wondering if there is any way to do it.

I am ideally expecting a few function calls to the ghc-api but I am also open to any suggestions that include (not-so-extensive) hacking in the source of GHC. Any pointers would help!

2
"Currently (as of version 6.8.2), GHC does not have the ability to read in External Core files as source." You would have to produce a representation in internal core and pass that to GHC, I'm afraid. For your sake I hope I'm overly pessimistic, but I believe you'd need far more than a few calls to the ghc-api.Daniel Fischer

2 Answers

11
votes

Note that Core is an explicitly typed language, which can make it quite difficult to generate from other languages (the GHC type checker has inferred all the types so it's no problem there). For example, the usual identity function (id = \x -> x :: forall a. a -> a) becomes

id = \(a :: *) (x :: a) -> a

where a is a type variable of kind *. It is a term-level place-holder for the type-level forall binding. Similarly, when calling id you need to give it a type as its first argument, so the Haskell expression (id 42) gets translated into (id Int 42). Such type bindings and type applications won't be present in the generated machine code, but they are useful to verify compiler transformations are correct.

On the bright side, it might be possible to just generate Haskell -- if you can generate the code in such a way that GHC will always be able to determine its type then you are essentially just using a tiny subset of Haskell. Whether this can work depends very much on your source language, though.

5
votes

There's still no way to read External Core files, whether via the ghc command or the API. Sorry :(

It's probably theoretically possible to build the Core syntax tree up from your representation using the GHC API, but that sounds very painful. I would recommend targeting some other backend. You don't necessarily have to stop using GHC; straightforward Haskell with unboxed types and unsafeCoerce lets you get pretty close to the resulting Core, so you could define your own simple "Core-ish" language and compile it to that. (Indeed, you could probably even compile GHC Core itself, but that's a bit too meta for my tastes.)