doc/guide/src/Projects.adoc

   1 Projects
   2 ========
   3
   4 We have lots of ideas for projects to improve MLton, many of which we
   5 do not have time to implement, or at least haven't started on yet.
   6 Here is a list of some of those improvements, ranging from the easy (1
   7 week) to the difficult (several months).  If you have any interest in
   8 working on one of these, or some other improvement to MLton not listed
   9 here, please send mail to
  10 mailto:MLton-devel@mlton.org[`MLton-devel@mlton.org`].
  11
  12 * Port to new platform: Windows (native, not Cygwin or MinGW), ...
  13 * Source-level debugger
  14 * Heap profiler
  15 * Interfaces to libraries: OpenGL, Gtk+, D-BUS, ...
  16 * More libraries written in SML (see <!ViewGitProj(mltonlib)>)
  17 * Additional constant types: `structure Real80: REAL`, ...
  18 * An IDE (possibly integrated with <:Eclipse:>)
  19 * Port MLRISC and use for code generation
  20 * Optimizations
  21 ** Improved closure representation
  22 +
  23 Right now, MLton's closure conversion algorithm uses a simple flat closure to represent each function.
  24 +
  25 *** http://www.mlton.org/pipermail/mlton/2003-October/024570.html
  26 *** http://www.mlton.org/pipermail/mlton-user/2007-July/001150.html
  27 *** <!Cite(ShaoAppel94)>
  28 ** Elimination of array bounds checks in loops
  29 ** Elimination of overflow checks on array index computations
  30 ** Common-subexpression elimination of repeated array subscripts
  31 ** Loop-invariant code motion, especially for tuple selects
  32 ** Partial redundancy elimination
  33 *** http://www.mlton.org/pipermail/mlton/2006-April/028598.html
  34 ** Loop unrolling, especially for small loops
  35 ** Auto-vectorization, for MMX/SSE/3DNow!/AltiVec (see the http://gcc.gnu.org/projects/tree-ssa/vectorization.html[work done on GCC])
  36 ** Optimize `MLton_eq`: pointer equality is necessarily false when one of the arguments is freshly allocated in the block
  37 * Analyses
  38 ** Uncaught exception analysis