mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-17 14:57:03 +00:00
cca3d674e1
Estimated hours taken: 50 Branches: main Added parsing and pretty printing of new promise ex declarations, and appropriate documentation. library/ops.m: Added the new operators to op_table. compiler/prog_io.m: Added clauses to enter promise ex declarations into the parse tree. compiler/prog_out.m: Added predicates useful in outputting promise declarations. compiler/prog_data.m: Changed assertion constructor in type item to a more gereral promise constructor to be used for assertions and promise ex declarations. Added the type promise_type to differentiate between different promise declarations. compiler/mercury_to_mercury.m: Added clauses to output promise items, including assertions and promise ex declarations. compiler/make_hlds.m: compiler/module_qual.m: compiler/modules.m: compiler/recompilation_check.m: compiler/recompilation_version.m: Updated to reflect change in item type. compiler/notes/glossary.html: Added new terminology, updated use of `promise'. compiler/notes/todo.html: Added todo list for promise ex declarations. compiler/notes/promise_ex.html: A new file documenting development of promise ex declarations.
358 lines
8.7 KiB
HTML
358 lines
8.7 KiB
HTML
<html>
|
|
<head>
|
|
<title>To Do List</title>
|
|
</head>
|
|
|
|
<body bgcolor="#ffffff" text="#000000">
|
|
|
|
<hr>
|
|
<!-------------------------->
|
|
|
|
<h1> TODO LIST </h1>
|
|
|
|
<hr>
|
|
<!-------------------------->
|
|
|
|
<p>
|
|
|
|
|
|
For more information on any of these issues, contact mercury@cs.mu.oz.au.
|
|
|
|
<p>
|
|
|
|
<h2> syntax </h2>
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
<li> Warn about the use of the deprecated old-style lambda expressions.
|
|
|
|
</ul>
|
|
|
|
<h2> type system </h2>
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
<li> Fix the three known type inference bugs (see comments in typecheck.m).
|
|
|
|
</ul>
|
|
|
|
<h2> mode analysis </h2>
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
<li> 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)'.
|
|
|
|
<li> 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]
|
|
|
|
<li> report an error if two mode declarations for a predicate
|
|
specify identical modes.
|
|
|
|
<li> 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.
|
|
|
|
</ul>
|
|
|
|
<h2> determinism analysis </h2>
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
<li> add functionality for promise ex declarations:
|
|
<ul>
|
|
<li> add error checking and type checking as for assertions
|
|
<li> include declaration information in the module_info
|
|
<li> take into account mutual exclusivity from promise_exclusive
|
|
and promise_exclusive_exhaustive declarations during switch
|
|
detection
|
|
<li> take into account exhaustiveness from promise_exhaustive and
|
|
promise_exclusive_exhaustive declarations during
|
|
determinism analysis
|
|
</ul>
|
|
</ul>
|
|
|
|
|
|
<h2> unique modes </h2>
|
|
|
|
<ul>
|
|
<li> handle nested unique modes
|
|
|
|
<li> we will probably need to extend unique modes a bit,
|
|
in as-yet-unknown ways; need more experience here
|
|
|
|
</ul>
|
|
|
|
<h2> module system </h2>
|
|
|
|
<ul>
|
|
<li> check that the interface for a module is type-correct
|
|
independently of any declarations or imports in the implementation
|
|
section
|
|
|
|
<li> there are some problems with nested modules (see the language
|
|
reference manual)
|
|
|
|
</ul>
|
|
|
|
<h2> C interface </h2>
|
|
|
|
<ul>
|
|
<li> exporting things for manipulating Mercury types from C
|
|
|
|
<li> better support for types defined in C
|
|
|
|
<li> need to deal with memory management issues
|
|
|
|
</ul>
|
|
|
|
<h2> code generation </h2>
|
|
|
|
<ul>
|
|
<li> take advantage of unique modes to do compile-time garbage collection
|
|
and structure reuse.
|
|
|
|
</ul>
|
|
|
|
<hr>
|
|
<!-------------------------->
|
|
|
|
|
|
<h1> WISH LIST </h1>
|
|
|
|
<h2> type-system </h2>
|
|
|
|
<ul>
|
|
<li> allow explicit type qualifications `X : Type'
|
|
[already done, but need to change module qualifier op to `.' first]
|
|
|
|
<li> allow std_util:construct/4 to work for existential types
|
|
|
|
<li> remove limitation that higher-order terms are monomorphic.
|
|
i.e. allow universal quantifiers at the top level of
|
|
higher-order types, e.g. <samp>:- pred foo(all [T] pred(T)).</samp>.
|
|
|
|
<li> constructor classes
|
|
|
|
<li> 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]
|
|
|
|
<li> subtypes?
|
|
|
|
<li> optimisation of type representation and manipulation (possibly
|
|
profiler guided)
|
|
|
|
<li> fold/unfolding of types
|
|
</ul>
|
|
|
|
<h2> mode analysis </h2>
|
|
|
|
<ul>
|
|
<li> split construct/deconstruct unifications into their atomic
|
|
"micro-unification" pieces when necessary.
|
|
(When is it necessary?)
|
|
|
|
<li> handle polymorphic modes (some research issues?)
|
|
|
|
<li> handle abstract insts in the same way abstract types are handled
|
|
(a research issue - is this possible at all?)
|
|
|
|
<li> implement `willbe(Inst)' insts, for parallelism
|
|
|
|
<li> mode segments & high-level transformation of circularly moded programs.
|
|
</ul>
|
|
|
|
<h2> determinism analysis: </h2>
|
|
|
|
<ul>
|
|
<li> propagate information about bindings from the condition of an if-then-else
|
|
to the else so that
|
|
<pre>
|
|
(if X = [] then .... else X = [A|As], ...)
|
|
</pre>
|
|
is considered det.
|
|
|
|
<li> turn chains of if-then-elses into switchs where possible.
|
|
[done by fjh, but not committed; zs not convinced that
|
|
this is a good idea]
|
|
|
|
</ul>
|
|
|
|
<h2> higher-order preds: </h2>
|
|
|
|
<ul>
|
|
<li> 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.
|
|
|
|
<li> allow taking the address of a predicate with multiple modes
|
|
|
|
<li> improve support for higher-order programming, eg. by providing
|
|
operators in the standard library which do things like:
|
|
<ul>
|
|
<li>compose functions
|
|
<li>take a predicate with one output argument and treat it like a function.
|
|
ie. <tt>:- func (pred(T)) = T.</tt>
|
|
</ul>
|
|
</ul>
|
|
|
|
<h2> module system: </h2>
|
|
|
|
<ul>
|
|
<li> produce warnings for implementation imports that are not needed
|
|
|
|
<li> 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]
|
|
</ul>
|
|
|
|
<h2> code generation: </h2>
|
|
|
|
<ul>
|
|
<li> use floating point registers
|
|
|
|
<li> allow floating point fields of structures without boxing
|
|
(need multi-word fields)
|
|
|
|
<li> inter-procedural register allocation
|
|
|
|
<li> stack allocation of structures
|
|
|
|
<li> retarget code generator to Java VM
|
|
</ul>
|
|
|
|
<h2> source-level transformations </h2>
|
|
|
|
<ul>
|
|
<li> more work on module system, separate compilation, and the multiple
|
|
specialisation problem
|
|
|
|
<li> extended DCGs
|
|
|
|
<li> transform non-tail-recursive predicates into tail-recursive form
|
|
using accumulators
|
|
[being worked on by petdr]
|
|
|
|
<li> improvements to deforestation / partial deduction
|
|
|
|
</ul>
|
|
|
|
<h2> low-level optimizations </h2>
|
|
|
|
<ul>
|
|
<li> reduce the overhead of higher-order predicate calls (avoid copying
|
|
the real registers into the fake_reg array and back)
|
|
|
|
<li> tail recursion optimization using pass-by-reference argument conventions
|
|
[being worked on by dmo]
|
|
|
|
<li> other specializations, e.g. if argument is known to be bound to
|
|
f(X,Y), then just pass X and Y in registers
|
|
|
|
<li> 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.
|
|
</ul>
|
|
|
|
|
|
<h2> compilation speed </h2>
|
|
|
|
<ul>
|
|
<li> improve efficiency of the expansion of equivalence types (currently O(N^2))
|
|
(e.g. this is particularly bad when compiling live_vars.m).
|
|
|
|
<li> improve efficiency of the module import handling (currently O(N^2))
|
|
|
|
<li> improve the efficiency of mode checking very large facts
|
|
(e.g. this is particularly bad when compiling eliza.m).
|
|
|
|
</ul>
|
|
|
|
|
|
<h2> better diagnostics </h2>
|
|
|
|
<ul>
|
|
<li> optional warning for any implicit quantifiers whose scope is not
|
|
the entire clause (the "John Lloyd" option :-).
|
|
|
|
<li> give a better error message for the use of if-then without else.
|
|
|
|
<li> give a better error message for the use of `<=' instead of `=<'
|
|
(but how?)
|
|
|
|
<li> give a better error message for type errors involving higher-order pred
|
|
constants (requested by Bart Demoen)
|
|
|
|
<li> give better error messages for syntax errors in lambda expressions
|
|
</ul>
|
|
|
|
<h2> general </h2>
|
|
|
|
<ul>
|
|
<li> coroutining and parallel versions of Mercury
|
|
|
|
<li> implement streams (need coroutining at least)
|
|
|
|
<li> implement a very fast turn-around bytecode compiler/interpreter/debugger,
|
|
similar to Gofer
|
|
[not-so-fast bytecode compiler done, but bytecode interpreter
|
|
not implemented]
|
|
|
|
<li> implement "accurate" garbage collection
|
|
|
|
<li> implement parallel garbage collection
|
|
|
|
<li> implement user-defined operators: <br>
|
|
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?
|
|
|
|
<li> support for easier formal specification translation (eg a Z library,
|
|
or Z to Mercury).
|
|
|
|
<li> improve support for constraint programming
|
|
|
|
<li> implement a source visualisation tool
|
|
|
|
<li> distributed Mercury
|
|
|
|
<li> improved development environment
|
|
|
|
<li> additional software engineering tools
|
|
<ul>
|
|
<li> coverage analysis
|
|
<li> automatic testing
|
|
</ul>
|
|
|
|
<li> literate Mercury
|
|
|
|
<li> implement a GUI library (eg Hugs - Fudgets)
|
|
|
|
<li> profiling guided optimisations
|
|
<ul>
|
|
<li> use profiling information to direct linker for optimal
|
|
code placement (Alpha has a tool for this).
|
|
</ul>
|
|
|
|
<li> use of attribute grammar technology
|
|
(including visit sequence optimization)
|
|
to implement code with circular modes
|
|
</ul>
|
|
|
|
<hr>
|
|
<!-------------------------->
|
|
|
|
Last update was $Date: 2002-02-08 02:27:12 $ by $Author: lljy $@cs.mu.oz.au. <br>
|
|
</body>
|
|
</html>
|