I’ve been thinking for a while that it ought to be possible to get Epigram to write out haskell code for ghc to compile, suitably annotated with unsafeCoerce# so as to get past the type checker. I finally got around to experimenting with this the other day; you can see some of the results here (generated from this).
This code is (mostly, apart from the Haskell interface glue at the top) generated by a tool I’m working on for a completely different reason from my usual noddy test functions: factorial, variadic adder and vector sum. I’ve tested it on some more complex code, but this example (factorial in particular) gives some idea of how fast it goes (about 1 second to compute 9! on my machine). Perhaps if I get a moment later this week I’ll try to make a more interesting program.
You can use the tool to generate haskell code yourself; the “Compile” command does the job (eg I used Compile “Nat”). You do have to write the interface glue by hand though.
There’s a lot of weird stuff in that file which is designed to convince GHC not to unbox things which shouldn’t be unboxed, etc. If you turn on any optimisations, it breaks. But it’s nice to know that this might be a possible route for generating compiled Epigram code that people could actually use…
I do wonder if the GHC people would expect this sort of thing to work though. I don’t imagine they would support this kind of abuse/subversion of the type system!
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?)
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.
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!
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…
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…