[Haskell-cafe] Google Summer of Code idea of project & application

[Chris Smith]

On Mon, Mar 19, 2012 at 7:52 PM, Richard O'Keefe <ok at cs.otago.ac.nz> wrote:
> As just one example, a recent thread concerned implementing
> lock-free containers.  I don't expect converting one of those
> to OCaml to be easy...

If you translate to core first, then the only missing bit is the
atomic compare-and-swap primop that these structures will depend on.
Maybe that exists in OCaml, or maybe not... I wouldn't know.  If not,
it would be perfectly okay to refuse to translate the atomic
compare-and-swap primop that lockless data structures will use.  That
said, though, there are literally *hundreds* of GHC primops for tiny
little things like comparing different sized integers and so forth,
that would need to be implemented.... all on top of the interesting
task of doing language translation.  That should be kept in mind when
estimating the task.

> If, however, you want to make it possible for someone to
> write code in a sublanguage of Haskell that is acceptable
> to a Haskell compiler and convert just *that* to OCaml, you
> might be able to produce something useful much quicker.

I'm quite sure, actually, that implementing a usable sublanguage of
Haskell in this way would be a much larger project even than
translating core.  A usable sublanguage of Haskell would need a
parser, which could be a summer project all on its own if done well
with attention to errors and a sizeable test suite.  It would need an
implementation of lazy evaluation, which can be quite tricky to get
right in a thread-safe and efficient way.  It would need type checking
and type inference that's just different enough from OCaml that you'd
probably have to write a new HM+extensions type checker and inference
engine on your own, and *that* could again be far more than a summer
project on its own, if you plan to build something of production
quality.  It would need a whole host of little picky features that
involve various kinds of desugarings that represent man-decades worth
of work just on their own.

After a bit of thought, I'm pretty confident that the only reasonable
way to approach this project is to let an existing compiler tackle the
task of converting from Haskell proper to a smaller language that's
more reasonable to think about (despite the problems with lots of
primops... at least those are fairly mechanical).  Not because of all
the advanced language features or libraries, but just because
re-implementing the whole front end of a compiler for even a limited
but useful subset of Haskell is a ludicrously ambitious and risky
project for GSoC.

-- 
Chris Smith