Enrico Tassi [Tue, 19 Oct 2010 13:25:32 +0000 (13:25 +0000)]
camlp5 probably changed some internal data structures and now they cannot be compared with pervasives.comapre, thus we avoid it. Was breaking the natural deduction stuff
Enrico Tassi [Sun, 17 Oct 2010 09:08:05 +0000 (09:08 +0000)]
new case for higher order unification:
(? ?) =?= (f x)
is not handled by delift, since flexible arguments in the local context
are skipped by delift, resulting in the instantiation of the head meta to
a constant function, even if the rhs is structurally the same.
Andrea Asperti [Fri, 8 Oct 2010 10:30:47 +0000 (10:30 +0000)]
- hmysql removed (RIP)
- library simplified to handle only new files, moo and lexicon
- BROKEN FEATURES: recursive decompilation of library files is currently
broken since, without the db, there is currently no way to compute the
reverse dependencies
1)
===========
It is an old and know issue. The check_stack calls fo_unif_w_hints only
on a prefix of applications, leaving some arguments on the stack. This
prevents hints to be found. Example
Hint: And A B === fun_of_morph And_morphism A B
If the problem
And A B =?= fun_of_morph ? A B
is found immediately (before entering the KAM) the it is solved, but if
it shows up inside the KAM, A and B are left on the stack and a
fo_unif_w_hints has to solve
And =?= fun_of_morph ?
While one could declare hints multiple times, varying the number of
actual arguments, I believe that the right solution is to make the
KAM code pass more information to fo_unif_w_hints, like the remaining
arguments. Nevertheless, the new fo_unif_w_hints is hard to factor with
the old one (that is used elsewere) so I wrote a new one called
fo_unif_heads_and_cont_or_unwind_and_hints. It first tries fo_unif on
the heads, and if successfull call a continuation (that will unify
all stack arguments pairwise) or unwinds the machine and looks for hints
on the complete terms, not just a prefix.
2)
===========
The fo_unif function does some clever higher order unification in the
case
(? x1 ... xn) =?= (t y1 ... ym)
but in the very similar case
K (? x1 ... xn) _ =?= (t y1 ... ym)
it does not.
K has to be reduced away, and afterwards the KAM configuration
has ? and t as heads, xs and ys on the stack. Assume m-n=l, the
unification problems generated by the check_stack function are
? =?= t y1 .. yl
xi =?= yl+i for i in 1 .. n
That is clearly suboptimal, since xn and ym could differ, but a clever
instantiation of the flexible head could drop or move around xm.
Moreover one expects the two unification problems to be solved in the
same way by the system, but it does not, and in my case the second one
actually fails. The KAM code should just be a speedup over a naive
unfolding of constants, beta-iota-zeta reduction and fo_unif, but in
this (unfortunate) case it is weaker.
3)
============
The delift function does a lot of work even if the metavariable is being
instantiated with a closed term. This is very often the case when the
term is suggested by hints. Hints may suggest constants in partially
unfolded form (see paper submitted to Type09), that can thus be very
big. This simple patch speeds up delift in this case.
1)
===========
It is an old and know issue. The check_stack calls fo_unif_w_hints only
on a prefix of applications, leaving some arguments on the stack. This
prevents hints to be found. Example
Hint: And A B === fun_of_morph And_morphism A B
If the problem
And A B =?= fun_of_morph ? A B
is found immediately (before entering the KAM) the it is solved, but if
it shows up inside the KAM, A and B are left on the stack and a
fo_unif_w_hints has to solve
And =?= fun_of_morph ?
While one could declare hints multiple times, varying the number of
actual arguments, I believe that the right solution is to make the
KAM code pass more information to fo_unif_w_hints, like the remaining
arguments. Nevertheless, the new fo_unif_w_hints is hard to factor with
the old one (that is used elsewere) so I wrote a new one called
fo_unif_heads_and_cont_or_unwind_and_hints. It first tries fo_unif on
the heads, and if successfull call a continuation (that will unify
all stack arguments pairwise) or unwinds the machine and looks for hints
on the complete terms, not just a prefix.
2)
===========
The fo_unif function does some clever higher order unification in the
case
(? x1 ... xn) =?= (t y1 ... ym)
but in the very similar case
K (? x1 ... xn) _ =?= (t y1 ... ym)
it does not.
K has to be reduced away, and afterwards the KAM configuration
has ? and t as heads, xs and ys on the stack. Assume m-n=l, the
unification problems generated by the check_stack function are
? =?= t y1 .. yl
xi =?= yl+i for i in 1 .. n
That is clearly suboptimal, since xn and ym could differ, but a clever
instantiation of the flexible head could drop or move around xm.
Moreover one expects the two unification problems to be solved in the
same way by the system, but it does not, and in my case the second one
actually fails. The KAM code should just be a speedup over a naive
unfolding of constants, beta-iota-zeta reduction and fo_unif, but in
this (unfortunate) case it is weaker.
3)
============
The delift function does a lot of work even if the metavariable is being
instantiated with a closed term. This is very often the case when the
term is suggested by hints. Hints may suggest constants in partially
unfolded form (see paper submitted to Type09), that can thus be very
big. This simple patch speeds up delift in this case.
Change (or better define) the order of hints premises.
They are now processed top to bottom, and not viceversa as before. This seems
to be right thing, since rules like:
X := carr T
....
R := mk_foo ... (P X) ... T ...
--------------------------------- |-
carr R = (P X)
can't be written putting X := carr T last, but you really want to be sure that
the needed assumptions to obtain a foo (in that case, that X is the carrier of
a setoid T) are available _before_ you even try to typecheck the bigger
unification problem (that may not be well typed if X and carr T are not
_convertible_, since in the fix function called in instantiate we call the
typechecker and not the refiner).
Some refactoring in set*.ma, some new notations and new hints for \cup.
non uniform coercions still to be pushed from re-setoids.ma to a place
before sets.ma, maybe in hints_declaration.ma since they are complementary.
Ferruccio Guidi [Fri, 6 Aug 2010 23:26:57 +0000 (23:26 +0000)]
ld.dtd: updated to comply with crg
Makefiles: updated to comply with new HELM server configuration
top: some traces of old command line option "-m" removed
Ferruccio Guidi [Fri, 6 Aug 2010 18:23:25 +0000 (18:23 +0000)]
we renamed the module abbreviations according to src/modules.ml
ld.dtd: now is more strict
Makefiles: some refactoring
crg: bug fix in name/indexes translation
xmlLibrary: bug fix in the rendering of the "name" attribute: ^ is
forbidden in a NMTOKEN
brgOutput: new xml exportation via xmlCrg
Ferruccio Guidi [Fri, 6 Aug 2010 10:21:49 +0000 (10:21 +0000)]
txtLexer: bug fix in parsing the string tokens
library: we now export the "meta" attribute
crgXml: crg exportation factorized and alpha conversion now works
crgBrg: we now mark the abstraction and the reverse translation works
ld.dtd: updated to export crg contents
Ferruccio Guidi [Tue, 3 Aug 2010 20:54:58 +0000 (20:54 +0000)]
- we simplified the parser return values
- now the display of parser and lexer debug information is controlled
from the command line (with the options -P and -L)
complete_rg: now the empty binders are not treated especially
top: we isolated a fragment of slow code (process_streaming) to be
investigated. It can be enabled with the -1 command line option)
Makefile: we now create the etc directory when it is missing
Experimental enhancements to the ndestruct tactic. By using the syntax
ndestruct (e1 ... em) skip (H1 ... Hn)
the user can tell the tactic that
- only equations e1 ... em should be considered
- rewriting should happen only in hypotheses H1 ... Hn and in the goal
both "(e1 ... em)" and "skip (H1 ... Hn)" are optional parameters.