Comments on: GHC back end?

By: Edwin Brady

Edwin Brady — Mon, 13 Feb 2006 13:42:53 +0000

I wondered if you’d say that :). I think it ought to be possible to get partial evaluation behaviour this way, with a suitably cunning representation of datatypes and compiled implementation of the elimination rules. For the moment, I was just interested in seeing if it might work at all.

So the compiled code for partial evaluation will need to be slightly different — but of course we knew that already. I’ll see what I can cook up…

By: Conor

Conor — Sat, 11 Feb 2006 11:17:59 +0000

Usual remark: I’d like to generate direct Haskell code implementing the partial evaluation behaviour too, then link compiled code back into the typechecker. I think it’s a very good time to be doing cheap lightweight experiments in compiling Epigram. I’m very interested to see whether more guarantees about totality, and perhaps more crucially, the separation of data from codata have any impact on the usual strict/lazy trade-offs. I also fancy fooling about with a variety of optimizations, given more explicit information about the recursive structure of programs and a fully-fledged partial evaluator. PS Out of purdah on the OTT paper; let’s see what next week brings forth…

By: Edwin Brady

Edwin Brady — Fri, 10 Feb 2006 15:05:17 +0000

I don’t see any reason why OCaml shouldn’t work just as well, given Obj.magic – my main reason for trying GHC instead is simply that I’m more familiar with it and so I’d rather have a Haskell interface to epigram code.

We could go to C directly (and indeed I did implement this too, a while ago (and I think it still works)) but I expect that going via the back end of an already mature, efficient functional language compiler (whether that be a haskell or ocaml) is better than what I can knock up in my spare time!

By: Carl Witty

Carl Witty — Fri, 10 Feb 2006 08:59:21 +0000

Total off-the-wall comment…

Have you considered generating OCaml code instead? I get the impression that Obj.magic (the OCaml equivalent of unsafeCoerce#) works fairly reliably for these sorts of tricks (for instance, see http://www.iist.unu.edu/~alumni/software/other/inria/www/caml/caml-list/0937.html).

I’m sure GHC has a much better implementation of laziness than OCaml, but optimized OCaml might still be comparable to unoptimized GHC.

By: Jon

Jon — Thu, 09 Feb 2006 15:32:09 +0000

GHC still generates C which is passed to GCC, right? So you’re suggesting epigram -> haskell -> c -> ELF ; missing out the intermediate compiler representations. I wonder how feasible it would be to implement a “user oriented” language at the top of a gigantic stack of intermediate languages, adding one feature per IL (how much waste would there be in having so many compilers in the middle?)