[MLton] approaches to parallelism in ML

[skaller]

On Tue, 2006-10-10 at 19:31 -0400, Matthew Fluet wrote:

> I would say that porting to one of these projects is actually 
> significantly easier than a native codegen.  My "port" to C-- was the work 
> of two weekends to get something that successfully compiled almost all 
> benchmarks.  The advantage of these projects is that they are providing 
> register allocation, calling convention implementation, etc.  Yes, if they 
> get one of those facets wrong, you need to wait for a bug fix from them.

That's not the main problem -- you can always join the project
and help, at least by providing test cases.

The real problem is you have to choose between building
the sources yourself (inside MLton) and suffering a
nightmare porting changes to your fork, or you just pass
the buck to the client, and have to suffer from losing
most of them.

Felix is running 4 forks: Frontc, Cil, Elkhound, and Tre.
We hope to convert Tre to forking only the build system,
and using the in-repository source.

The biggest problem here is NOT the source code:
it's the build systems. Felix for example,
will not permit any bash or make script, let alone
autotools rubbish: all our build script is required
to be portable Python.

We also depend on 3 standalones: Python, Ocaml,
and a C++ compiler: they use their own build systems
and we provide Ocaml/C++ integration via Python.

It's very unfortunate we can't ignore Windows, since
Apple has now come into the Unix fold its more
tempting .. :)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net