We have lots of ideas for improvements to MLton, many of which we do not
have time to implement, or at least haven't started on yet. Here is a list
of some of those improvements, ranging from the easy (1 week) to the
difficult (several months). If you have any interest in working on one of
these, or some other improvement to MLton not listed here, please send mail
to MLton@mlton.org.
- Optimizations
- Improved closure representation.
Right now, MLton's closure conversion algorithm uses a simple flat
closure to represent each function.
- Elimination of array bounds checks in loops.
- Elimination of overflow checks on array index computations.
- Common-subexpression elimination of repeated array subscripts.
- Loop-invariant code motion, especially for tuple selects.
- Profiler.
- Relate to the source code.
- Debugger.
Build one.
- It shouldn't be too hard to spit out stabs data similar to what
the profiler does now, relating to the SSA code.
- Relate to the source code
- Port CML.
The support for threads and signals is already there, so
it shouldn't be too hard to change the uses of callcc to
MLton.thread.switch. Harder is thinking about how to make MLton's
libraries thread safe.
- Libraries.
- Add support for 64 bit integers, and use them for file
positions.
- Interface to gtk+.
- Interface to OpenGL.
- Any useful additions to the MLton structure.
- Transform the compiler libraries used within MLton into generally
useful libraries.
Last modified: Tue Apr 9 16:17:22 PDT 2002