download
| history
| home
| papers
| performance
| projects
| team
| user guide
| users
We have lots of ideas for projects to improve 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.
- Port to new platform: Windows, Mac OSX, x86-64, ...
- Proper front end
- Source-level debugger
- Support calling SML from C
- Heap profiler
- Support NLFFI
- Interfaces to libraries: Gtk, OpenGL, ...
- Additional constant types: Int64, Real32, Real80, Word64, ...
- Use Int64 for file positions
- Support 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.
- Port MLRISC and use for code generation
- Optimizations
- Improved closure representation
Right now, MLton's closure conversion algorithm uses a simple flat
closure to represent each function.
- Array, ref, and vector flattening
- 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
MLton
Last modified: Mon Jul 7 16:21:09 PDT 2003