1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
|
<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>
<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> use_module should not be transitive
(currently we get this right for predicates, constants, and functors,
but wrong for types, insts, and modes).
<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: 1999/12/11 16:36:47 $ by $Author: fjh $@cs.mu.oz.au. <br>
</body>
</html>
|
