                                   TODO LIST

   Note that this list is old, and not really maintained anymore.

   For more information on any of these issues see our [1]contacts page.

mode analysis

     * fix various bugs in mode inference: need to fix it to work properly
       in the presence of functions; also need to change normalise_inst so
       that it handles complicated insts such as `list_skel(any)'.
     * extend the mode system to allow known aliasing. This is needed to
       make partially instantiated modes and unique modes work. [supported
       on the "alias" branch, but there were some serious performance
       problems... has not been merged back into the main branch]

determinism analysis

     * add functionality for promise exclusive declarations:
          + add error checking and type checking as for assertions
          + include declaration information in the module_info
          + take into account mutual exclusivity from promise_exclusive
            and promise_exclusive_exhaustive declarations during switch
            detection
          + take into account exhaustiveness from promise_exhaustive and
            promise_exclusive_exhaustive declarations during determinism
            analysis

unique modes

     * handle nested unique modes
     * we will probably need to extend unique modes a bit, in
       as-yet-unknown ways; need more experience here

module system

     * check that the interface for a module is type-correct independently
       of any declarations or imports in the implementation section
     * there are some problems with nested modules (see the language
       reference manual)

C interface

     * exporting things for manipulating Mercury types from C
     * need to deal with memory management issues

code generation

     * take advantage of unique modes to do compile-time garbage
       collection and structure reuse.

back-ends

  low-level (LLDS) back-end

     * support accurate garbage collection

  high-level C back-end

     * finish off support for accurate garbage collection; see the
       comments in compiler/ml_elim_nested.m
     * see also the comments in compiler/ml_code_gen.m

debugger

     * support back-ends other than LLDS
     * allow interactive queries to refer to values generated by the
       program being debugged
     * trace semidet unifications

Unicode

     * allow alternative external encodings, particularly iso-8859-1
     * consistent and robust handling of invalid strings (overlong
       sequences, unpaired surrogates, etc.)
     * add analogue of wcwidth and make some formatting procedures use it
     * io.putback_char depends on multiple pushback in ungetc for code
       points > 127
     __________________________________________________________________

                                   WISH LIST

type-system

     * allow construct.construct/3 to work for existential types
     * remove limitation that higher-order terms are monomorphic. i.e.
       allow universal quantifiers at the top level of higher-order types,
       e.g. :- pred foo(all [T] pred(T))..
     * constructor classes
     * allow a module exporting an abstract type to specify that other
       modules should not be allowed to test two values of that type for
       equality (similar to Ada's limited private types). This would be
       useful for e.g. sets represented as unordered lists with possible
       duplicates. [this is a subset of the functionality of type classes]
     * subtypes?
     * optimisation of type representation and manipulation (possibly
       profiler guided)
     * fold/unfolding of types

mode analysis

     * split construct/deconstruct unifications into their atomic
       "micro-unification" pieces when necessary. (When is it necessary?)
     * extend polymorphic modes, e.g. to handle uniqueness polymorphism
       (some research issues?)
     * handle abstract insts in the same way abstract types are handled (a
       research issue - is this possible at all?)
     * implement `willbe(Inst)' insts, for parallelism
     * mode segments & high-level transformation of circularly moded
       programs.

determinism analysis:

     * propagate information about bindings from the condition of an
       if-then-else to the else so that
        (if X = [] then .... else X = [A|As], ...)

       is considered det.
     * turn chains of if-then-elses into switches where possible. [done by
       fjh, but not committed; zs not convinced that this is a good idea]

higher-order preds:

     * implement single-use higher-order predicate modes. Single-use
       higher-order predicates would be allowed to bind curried arguments,
       and to have unique modes for curried arguments.
     * allow taking the address of a predicate with multiple modes [we do
       allow this in case where the mode can be determined from the inst
       of the high-order arguments]
     * improve support for higher-order programming, eg. by providing
       operators in the standard library which do things like:
          + compose functions
          + take a predicate with one output argument and treat it like a
            function. ie. :- func (pred(T)) = T.

source-level transformations

     * more work on module system, separate compilation, and the multiple
       specialisation problem
     * transform non-tail-recursive predicates into tail-recursive form
       using accumulators. (This is already done, but not enabled by
       default since it can make some programs run much more slowly. More
       work is needed to only enable this optimization in cases when it
       will improve performance rather than pessimize it.)
     * improvements to deforestation / partial deduction

code generation:

     * stack allocation of structures

LLDS back-end:

     * inter-procedural register allocation
     * other specializations, e.g. if argument is known to be bound to
       f(X,Y), then just pass X and Y in registers
     * reduce the overhead of higher-order predicate calls (avoid copying
       the real registers into the fake_reg array and back)
     * trim stack frames before making recursive calls, to minimize stack
       usage (this would probably be a pessimization much of the time -
       zs) and to minimize unnecessary garbage retention.

garbage collection

     * implement liveness-accurate GC
     * implement incremental GC
     * implement generational GC
     * implement parallel GC
     * implement real-time GC

compilation speed

     * improve efficiency of the expansion of equivalence types (currently
       O(N^2)) (e.g. this is particularly bad when compiling live_vars.m).
     * improve efficiency of the module import handling (currently O(N^2))
     * use "store" rather than "map" for the major compiler data
       structures

better diagnostics

     * optional warning for any implicit quantifiers whose scope is not
       the entire clause (the "John Lloyd" option :-).
     * give a better error message for the use of if-then without else.
     * give a better error message for the use of `<=' instead of `=<'
       (but how?)
     * give a better error message for type errors involving higher-order
       pred constants (requested by Bart Demoen)
     * give better error messages for syntax errors in lambda expressions

general

     * coroutining and parallel versions of Mercury
     * implement streams (need coroutining at least)
     * implement a very fast turn-around bytecode
       compiler/interpreter/debugger, similar to Gofer [not-so-fast
       bytecode compiler done, but bytecode interpreter not implemented]
     * support for easier formal specification translation (eg a Z
       library, or Z to Mercury).
     * implement a source visualisation tool
     * distributed Mercury
     * improved development environment
     * additional software engineering tools
          + coverage analysis
          + automatic testing
     * literate Mercury
     * implement a GUI library (eg Hugs - Fudgets)
     * profiling guided optimisations
          + use profiling information to direct linker for optimal code
            placement (Alpha has a tool for this).
     * use of attribute grammar technology (including visit sequence
       optimization) to implement code with circular modes

References

   1. http://www.mercurylang.org/contact.html
