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@sourcelight.com.

• Garbage collector.
  Right now, MLton's collector is breadth first, nongenerational, and tagged. We would be interested to see any of the 7 other possibilities by making a different choice in one or more of these dimensions (depth/breadth first, (non)generational, or tagged/tagless). Probably the easiest to do would be do change the collector to be depth first. Changing either of the other would require compiler support. In particular, making the collector tagless is an interesting research project.
• 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 repeated array bounds checks (common when a subscript is followed by an update.
  • Elimination of overflow checks on array index computations.
  • Common-subexpression elimination, especially of repeated selects from tuples and of repeated array subscripts.
  • Loop-invariant code motion, especially for tuple selects and array and vector lengths.
• Profiler.
  • Improve so that profiling can be controlled from within the program so that specific parts of a program can be compiled.
  • 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 CPS 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.

Here are some projects that we're already working on.

Henry Cejtin

Upgrading to a new version of gmp and exporting fast gcd algorithms.

Matthew Fluet

Improving representation of data structures so that the indirection in ref cells can sometimes be avoided and so that tuples can be flattened into arrays. Also, hopefully improve bool arrays, which currently use 32 bits per elt!

Stephen Weeks

A real front end.

---

Last modified: Fri Jul 6 13:34:03 PDT 2001