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