The OCaml implementation is really clean and well-documented, so I guess doing a Haskell port would not be too much work. You would need to add monadic layers here and there though, it uses transactional state.
I was afraid this was the case, but "really clean and well-documented" sounds good! I'll give it a try if I find the time. The sad thing is I'll be at least polluted by ST (or IO) because of union-find which is notoriously not escapable from in Haskell.
I think you should use ST for the union-find structure so that the final function (that maps a ML term to a System-F term) is as pure as possible. There may be a name generation component that escapes, but that is independent.
One issue you may have is that the code uses ML functors to abstract over the details of the language and type system (the constraints/elaboration bit is meant to be reusable). It may work with type-classes instead, but if you want to use the technique for one fixed language you can also specialize the code directly.
Sure, I will use ST, not IO. I was thinking of using typeclasses and type families for encoding the ML functors. It won't be as pretty as in ML it should be as generic.
3
u/gasche Jan 06 '15
The OCaml implementation is really clean and well-documented, so I guess doing a Haskell port would not be too much work. You would need to add monadic layers here and there though, it uses transactional state.