More on that compiler

I’ve been thinking about Epigram back ends again, and come up with this, which I hope will develop into more than just a toy:

http://www.dcs.st-and.ac.uk/~eb/esc.php

It is an implementation of a simple, mostly untyped, supercombinator language with a few bells and whistles for talking to the outside world, separate compilation, arbitrary precision arithmetic etc. Also, following the philosophy that computer programs might be used by other programs as well as humans, it exports an API – the idea would be that Epigram could target this API; the language itself is independent of whatever method Epigram might ultimately use for IO.

It is more generally useful though – anyone looking for a compiled back end for their own language implementation, but wanting to avoid having to write a run time system, might be interested in trying it. Evaluation is strict by default, but with optional laziness annotations.

I did a highly unscientific experiment, in which I wrote a tail recursive factorial program using Peano natural numbers in this, Haskell and OCaml, to compare speed. The ESC version runs in half the time of the Haskell (GHC) version, and about three times the time of the OCaml version. So I think that’s encouraging – it would be far better with unboxed integers, but for now it’s nice to know that it isn’t painfully slow!

Let me know if you make it work… next job is to work out how to hook it up to the current Term representation.

One Response to “More on that compiler”

  1. Conor says:

    Thank you for this. I’ll give it a shot when I get back to Nottingham tomorrow. The current term representation is a bit of a moving target, to be honest. Except that we’re pretty much determined that data is made of numerically tagged tuples (aka dependent tuples whose head is the tag from which the tail’s adicity(*) is computed), so it shouldn’t take too big a leap. What’s changing more rapidly is the typing apparatus on top of that. Peter and I are cooking quite intensely on a universe of datatypes for numerically tagged tuples. Hopefully, though, the bits we’re fiddling with are mostly due for erasure anyway.

    (*) adicity is to Σ as arity is to Π.

Leave a Reply