On Thursday 05 March 2009 20:50:58 Jake Donham wrote:
> On Thu, Mar 5, 2009 at 12:44 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> > Is this [the lambda IL] format documented anywhere?
>
> The ocamljs backend compiles Javascript from the lambda intermediate
> language. I haven't found documentation of it, but most of it is
> pretty easy to understand (a few things I've had to track down by
> seeing what they compile to in bytecode). You might find the
> Javascript translation a useful guide, but of course don't take it as
> the final word.
>
> You are right though that it makes some assumptions about the runtime
> representation and has already erased types. It is (obviously) good
> enough to be a shared IL for the bytecode and opt backends; it is
> mostly good enough for ocamljs (there are some places where I wish I
> knew more about the type of things); I can't say what your needs are
> with LLVM.
>
> Still it is probably a better starting point than trying to
> reimplement the OCaml front-end.

That's very interesting advice, thanks, but the more I play with it the more I 
think it will not satisfy my needs. Consider:

  type t = A of int | B of int | C of int;;
  function A n -> n | B n -> n | C n -> n;;

which compiles to:

  (setglobal A! (seq (function param/72 (field 0 param/72)) (makeblock 0)))

The type definition is not even there and the function definition swings 
entirely on the uniform internal representation of the field. That is 
completely incompatible with HLVM. The ocamljs backend will have an easier 
time because it will be dynamically typing everything anyway (i.e. it also 
has a uniform representation). I could do that in HLVM but the performance 
would be atrocious because everything would be boxed, of course.

I'll take a look at the pattern match compiler in OCaml and see if it is 
feasible to make it retain type information. Hopefully I can reuse some of 
this stuff. :-)

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e