TODO LIST
For more information on any of these issues, contact mercury@cs.mu.oz.au.
type system
- Fix the three known type inference bugs (see comments in typecheck.m).
mode analysis
- fix various bugs in mode inference;
in particular need to infer mostly-unique vs unique distinctions,
and need to fix it to work properly in the presence of functions.
- extend the mode system to allow known aliasing.
This is needed to make partially instantiated modes and unique modes work.
[being done by bromage, nearly finished]
- report an error if two mode declarations for a predicate
specify identical modes.
- detect incorrect usage of `bound(...)' insts.
That is, make sure that all of the functors in a bound(...) inst
are valid functors for the type.
determinism analysis
- allow overloading of nondet/multidet and cc_nondet/cc_multidet
determinism for the same mode of a predicate.
unique modes
- handle unique mode overloading better -
don't depend on the order of the mode declarations.
- handle overloading of unique and mostly_unique modes.
Currently in modes.m we always pick the unique version, and then in
unique_modes.m, if it turns out out to be mostly_unique, we report an
error. We should changed unique_modes.m to also look for a
mostly_unique version before reporting an error.
- 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
- imports should not be transitive
(currently we get this right for predicates, constants, and functors,
but wrong for types, insts, and modes).
C interface
- document it properly
- nondeterministic C code
- exporting things for manipulating Mercury types from C
- better support for types defined in C
code generation
- take advantage of unique modes to do compile-time garbage collection
and structure reuse.
WISH LIST
type-system
- allow explicit type qualifications `X : Type'
[already done, but need to change module qualifier op to `.' first]
- allow existential types at the top level of func or pred declarations,
e.g. :- some [T] (func univ_value(univ) = T)..
- allow existential types in data structures
- 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))..
- type 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?)
- handle polymorphic modes (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?
[will be done by conway]
- mode segments & high-level transformation of circularly moded programs.
determinism analysis:
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
module system:
- produce warnings for implementation imports that are not needed
- produce warnings for imports that are in the wrong place
(in the interface instead of the implementation, and vice versa)
[vice versa done by stayl]
code generation:
- use floating point registers
- allow floating point fields of structures without boxing
(need multi-word fields)
- The generated code should include some more profiling hooks.
In particular, we should add a version of the heap allocation
macro which takes an extra string parameter identifying which
routine allocated the memory. Then we can do heap-allocation
profiling to identify which routines use up all the bloody memory.
- inter-procedural register allocation
- stack allocation of structures
- retarget code generator to Java VM
source-level transformations
- more work on module system, separate compilation, and the multiple
specialisation problem
- extended DCGs
- transform non-tail-recursive predicates into tail-recursive form
using accumulators
- deforestation and partial deduction
[being worked on by stayl]
low-level optimizations
- reduce the overhead of higher-order predicate calls (avoid copying
the real registers into the fake_reg array and back)
- tail recursion optimization using pass-by-reference argument conventions
- other specializations, e.g. if argument is known to be bound to
f(X,Y), then just pass X and Y in registers
[being worked on by petdr]
- 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.
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))
- improve the efficiency of mode checking very large facts
(e.g. this is particularly bad when compiling eliza.m).
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
[being worked on by conway]
- implement streams (need coroutining at least)
- implement tabling
[tabling in the absence of negation done by ohutch, but not committed]
- implement a very fast turn-around bytecode compiler/interpreter/debugger,
similar to Gofer
[not-so-fast bytecode compiler done,
bytecode interpreter/debugger being worked on by aet]
- implement a new backend which compiles to high-level C that can
be debugged at the Mercury source code level using gdb
[a small start has been made by fjh]
- implement "accurate" garbage collection
[being worked on by trd]
- implement parallel garbage collection
- implement user-defined operators:
Add a new construct `:- op(Pred, Type, Op).' as in Prolog;
change prog_io.m to parse this construct and call io__op
accordingly. But how does this fit in with the module system?
- support for easier formal specification translation (eg a Z library,
or Z to Mercury).
- improve support for constraint programming
- 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
Last update was $Date: 1997/07/10 06:44:42 $ by $Author: zs $@cs.mu.oz.au.