Note - some non-critical bugs may be documented as TODO items.
(You need to have MetaPRL CVS account to be able to access the doc/private/TODO file.)

Note - some files have small bugs documented in their comments, these can be found
by rgrep'ing for the string "BUG".

DOCUMENTATION:

1.1) Documentation suggests to use mp and x.mp
while mpopt and mptop should be used instead.
Use Guide and Tutorial should mention the difference,
and suggest using mptop or mpopt. After that all examples should use mpopt.
1.1.1) In the mptop/mpopt vs mp discussion, the documentation should also mention readline
and give some pointers (info+man pages or readline homepage) to more information on customizing it.

1.2) Make system is not documented (see TODO 7.02 for more information).

1.3) (Created on 1999.11.11 by nogin)
Resources and resource annotations are not documented
1.3.1) The dT tactic section (doc/htmlman/system/mp-d-tactic.html) is not written.

1.4) (Created on 1999.11.11 by nogin)
MetaPRL Tutorial is very outdated.

EDITOR

2.1-2.4 are fixed

2.5) Display form mode generality is not working.

2.6) (Added 2000.02.21 by nogin)
When a list of subgoals is too big, displaying used to take a while. The current
workaround is to only display subgoals when there are <20 of them. We need to
find a better solution - in particular we should take into account subgoal sizes, not only
the number of subgoals.

It may be a good idea to implement a generic display-form mechanism to allow limiting

the number of lines a certain term would occupy. On the other hand, such an approach
would only save the time to output the display form, but not the time to produce it.

2.7) Native code just exits with segmentation fault on stack overflow. This is really bad
since it does not give user a chance to save work.
Note: tactic scheduler seems to use its own stack, so nothing back happens if a tactic
loops.

2.8) When ls is used with non-empty flags (e.g. ls "u"), it should not use the word
     "Implementation" in the listing header (or it should at least tell what exactly
     it is listing).

2.9) Display form mechanism does not give a way to distinguish between parameters
     and meta-parameters. Because of that terms with meta-parameters will very
     often display wrong.

REWRITER

(We are currently in the process of rethinking how exactly we want to do rewriting.
Because of that we stopped doing anything in the middle of reimplementations that left
some cases working incorrectly. This resulted in several bugs that we should be able
to fix pretty quickly if somebody would want us to).

3.1) If a variable is bound in a context, rewriter may handle it incorrectly.

3.2) If the same variable is bound several times in redex or contractum specification, rewriter
may handle it incorrectly. We can not prohibit repeated bound variable in redeces
specifications because of two-way rewrites.

3.3) If the same variable is bound several times in the matched term, rewriter may handle
it incorrectly.

Example:
test{x.test{y.'C['x; 'y]}} <--> 'C[1; 2]
rewrites <<test{x.test{x.'x}}>> to 1 instead of 2.

(3.4-3.5 - fixed)

3.6) Rewriter does not prevent capturing. It should, at least in the "strict" mode.
More specifically, if some SO variable occurs under some bound variable in
contractum, but not in the redex, then we need to check whatever matched that
SO variable for free vars and rename the bvar accordingly. Currently we never
do this.
   A particular case of this situation happens when we introduce a bound variable
in contractum that didn't exist in the redex. In this case a possible workaround
is to pass the variable name explicitly as an argument to the rule and than to
compute the correct name ourselves (using the maybe_new_var function) in a
tactic before calling the rule.
   When the workaround is not used (such as with x in Itt_prod.unfold_prod and
x1 in Itt_rfun.rfunctionEqualityA), the Rewrite_compile_redex.compile_bname
will produce the SaveName variant.
   After this bug is fixed, we should probably kill all the usage of the
maybe_new_var function in tactics.

3.7) Currently rewriter does not enforce building contractum to be against the same redex
the contractum was compiled against. Hopefully we never do this wrong, but we still
should enforce it.

3.8) SO contexts that are not a part of a sequent are currently never used and as a result
the corresponding rewriter code is undebugged.

3.9) (Added in 1999.11.05 by nogin, unverified)
If we have a redex where all the arguments of some SO variable are bound variables
and some variable appears more than once, rewriter may handle it incorrectly.
Example: <<lambda{x.lambda{y.'S['x;'x] +@ 'S['x;'y]}}>> should match
<<lambda{x.lambda{y.'x *@ 'x +@ 'x *@ 'y}}>>

3.10) (nogin) When the same variable appears twice in the same bvars list
(e.g., spread{p; x,x.x}), Nuprl upderstands it as y,x.x and MetaPRL - as x,y.x.
Nuprl's way is more natural and we should convert. I already wrote the new type
inference (only for spread) with Nuprl's understanding in mind.

3.11) (nogin; 2000.08.08)
When dT is ran on hypothesys x: exists i:'T..., y is used as a name of the new hypothesys
variable instead of i. I am not sure whether it's a rewriter problem or a bad tactic.
In particular, this breaks lots of proofs in itt_collection.

3.12) (fixed)

3.13) (kopylov; 2001.19.06)
RewriteInternal.rw intentional rewrite should apply conv the whole sequent.
After fixing this bug, rwcAll should use RewriteInternal.rw instead
of onAllMClausesT (conversionals_boot.ml).

3.14) (kopylov; 2001.19.06)
Converertions can not be applied to context.
E.g.  'H; 'J['A*'B >- C
# refine rw (reduceC) 1;;
    Term_addr_ds.term_subterm: [Hyp(1)]
    [ext] H; J[A * B] >- C
# refine rw (sweepUpC unfold_prod) 1;;
Refine error:
    Term_addr_ds.term_subterm: [Hyp(1)]
    [ext] H; J[A * B] >- C
After fixing this bug, higherC would be redundant in the definition
of applyAllC (conversionals_boot.ml).


REFINER

4.1) (fixed)

4.2) Repeated bound variables (when the same variable is bound more than once) is
handled incorrectly. For example, thinning rule does not check if the variable
is bound only once (which may be used to prove incorrect results). This is probably the
same bug as 3.3 (see also 4.11)

4.3) rwh does not do matching correctly - for example, it allows to use reduceEta
on <<lambda{x.('x 'x)}>>. This may be already fixed by the "strict" rewriter mode.

4.4) "Understanding" of extracts seems broken. When refiner passes extracts to rewriter,
it "forgets to mention" that they are in the scope of hypothesis variables.

One of the side-effects of this problem is that we have to pass unnecessary arguments
to some of the rules (such as Itt_struct.hypothesis and srecElimination;
note: Itt_struct.hypothesis is mentioned in doc/htmlman/user-guide/mp-axiom.html).

We may try to fix it using meta-variables - see TODO #1.05.1

4.5) Since unification is only used in proof search, but not proof checking, it should be OK
that we do not have any unification in term_std, but this may create problems,
so we may need to create some unification for term_std.

4.6) (Discovered 2000.04 by kopylov, confirmed by nogin)
Until by-context free variable restriction is implemented and its usage is enforced
when necessary (see doc/sequents.tex for more information), the rule chaining is not
necessarily valid (e.g. even when S1 --> S2 and S2 --> S3 are valid rules, S1 --> S3 is not
necessarily valid). See also TODO #6.01

4.7) (nogin)
In Ocaml, string is a mutable data structure. In MetaPRL, we use strings everywhere (variable
names, opnames, etc) as if they were immutable. We need to
a) Make sure that nobody can cheat the system by starting to mute strings.
b) Let the compiler and GC know that we are not going to mute strings (which should allow
them to be more efficient).

4.8-4.9) (fixed)

4.10) (2000.09.18 kopylov)
The extract of a subgoal of a rule should be of the form 't['x1;,,,;'xn], where 't is
a second order varible and 'x,...,'xn are ALL varibles declared in the hypothesis of the subgoal.
For example we should not be able to write rules with the subgoal of the form:
 ('t['x] : sequent ['ext] { 'H; x: 'A; y: B >- 'T['x] }) --> ....
or
 ('t+'s : sequent ['ext] { 'H >- 'T }) --> ....

See also BUGS #4.4

4.11) (fixed)

PARSER & FILTER

5.1-5.2) (fixed)

5.3) Some times parser requires too many brackets.

5.4) (fixed)

5.5) Toploop_resource seems to be added into .p4 file even if
   base_theory is not included.

5.6) (2000.05.30) Resource annotations on axioms (rules that have neither parameters nor
assumptions) are currently silently ignored.

5.7) (2001.07.18 nogin) Currently .prla ASCII IO requires stack size
proportional to the file size. This means that we will have a stack overflow
if .prla file is too big (I already had to increase the stack size because of
that). We should try to rewrite that code in a tail-recusive way.

RULES & REWRITES

6.1-6.2) (fixed)

6.3) See Bugzilla bugs 5,6,7.

6.4) Dependent product type is currently defined as a very dependent function type.
Unfortunatelly, we were not (yet) able to prove productElimination. We should
think whether it's true and if not, then define dprod differently.

6.5) Fixed

6.6) See Itt_bugs.bug1

BUILD SYSTEM

7.1) Dependencies between .prla, .prlb, .cmiz, .cmoz, etc., are all messed up
Solution: have MetaPRL maintain a file in each directory
with the list of valid files.  Have only one of .prla, .prlb, or .cmoz file
present at any time.  These files should not be in CVS.

Better solution: keep only one .prl file, can contain either binary or
ASCII.  Make CVS check that file is in ASCII before a commit.

Another problem is that when .prla is removed from the repository and
after "cvs update" removes it from the working copy, the old .prlb
becomes active instead of being deleted.

P.S. It's possible that cons (with its MD5 checksums) would be able to help
with this problem.

7.2-7.3) (fixed)
