Files
mercury/compiler/notes/TODO
1995-06-20 11:33:28 +00:00

156 lines
3.9 KiB
Plaintext

*******************************************************************************
TODO LIST:
----------
mode analysis
-------------
- handle "phantom aliasing", i.e. aliasing within a single procedure.
This is needed to make partially instantiated modes work.
- handle higher-order pred modes
- handle unique modes
- detect incorrect usage of `bound(...)' insts.
- split construct/deconstruct unifications into their atomic
"micro-unification" pieces when necessary.
(When is it necessary?)
determinism analysis
--------------------
- handle higher-order preds
code generation:
---------------
- generate code for complicated unifies in partially instantiated modes
general
-------
- implement "lambda" expressions.
- handle higher-order pred constants where the pred has a polymorphic type
(by converting to lambda expressions)
- renaming apart of different occurences
of the same variable; warning about variables which occur in
overlapping scopes.
- warn about non-underscore variables which occur only once in any given
branch, even if they occur in other branches.
mercury_to_goedel.m
-------------------
- see comments at the start of that file
module system
-------------
- check that the interface for a module is type-correct
independently of any declarations or imports in the implementation
section
- handle module qualifiers properly
- imports should not be transitive
(currently we get this right for predicates, constants, and functors,
but wrong for types, insts, and modes).
*******************************************************************************
WISH LIST
---------
typechecking
------------
- see wish list comments at the start of typecheck.m
mode analysis:
--------------
- 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?)
code generation:
----------------
- The generated code should include some 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.
- We could still generate better code for switches
general
-------
- optimization of various sorts
- Combining heap pointer increments in straight-line code into
a single increment (should be part of value number)
- "accurate" garbage collection
- 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
- improve efficiency of the implicit quantification pass (currently O(N^2))
- improve efficiency of the module import handling (currently O(N^2))
- more work on module system, separate compilation, and the multiple
specialization problem
- deforestation
- mode segments & high-level transformation of circularly moded programs.
- 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.
- optional warning for any implicit quantifiers whose scope is not
the entire clause (the "John Lloyd" option :-).
- warn about multiple calls to a predicate with the same input arguments,
because this is likely to be a programming mistake.
eg.
p(...) :-
...
q(InA, InB, OutC, OutD),
...
q(InA, InB, OutE, OutF).
should result in
Warning: redundant call to `q(InA, InB, _, _)'
- give a better error message for the use of if-then without else.
- give a better error message for type errors involving higher-order pred
constants
- issue a warning if the only use of an argument is in a recursive call
- better error handling
- fix all the `XXX's, `xxx's, `YYY's and `%%%'s.
- implement a debugger and a profiler
*******************************************************************************