
TODO
====

While the interpreter is already full-featured, there are still a few things
which would be nice to have in future releases.

(NB: These are just the most substantial wishlist items, which might well turn
out to be difficult or subprojects in their own right. Don't let this
discourage you from contributing smaller improvements if you notice any
shortcomings in the interpreter. -ag)

- Support for LLVM's debugging and profiling intrinsics to create code which
  can be debugged and profiled using external tools like gdb and gprof.

- Support for direct object (.o) file generation once LLVM supports this.
  This will make it possible to do batch compilation without having the LLVM
  toolchain installed.

- Better error recovery in the parser. Pure's terseness makes this rather
  difficult, however. Fortunately, the current panic mode recovery seems to
  cope surprisingly well with most common kinds of errors, although it might
  catch errors much too late in some cases.

- Multithreading support. This requires thread-local data instead of globals
  in a few places, and synchronization where interpreter globals are used
  (most notably, runtime compilation and expression memory management). We
  also need to add the necessary support functions to the runtime.

- Separate compilation and the ability to have several separate Pure libraries
  coexist in a single program. Unfortunately, Pure doesn't lend itself to
  separate compilation, as Pure function definitions consist of individual
  equational rules which may be scattered out over any number of source files,
  and may even be extended dynamically with equations entered by the user in
  the interpreter. Thus a Pure linker would need the capability to merge
  several existing function definitions into one.

- More aggressive optimizations, such as: common subexpression elimination for
  "pure" a.k.a. side-effect-free function calls; unboxed specializations of
  functions which only deal with basic numeric data types; call global
  functions directly when possible. (The latter is already done for direct
  recursive calls of globals, but this isn't really possible when using the
  JIT since in the interpreter we need the capability to patch up global
  functions dynamically. However, in principle it should be possible to design
  an LLVM optimization pass for batch compilation which substitutes direct
  calls for saturated applications of global functions.)
