Pas de solution à court terme pour ce problème de complexité

git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@9548 85f007b7-540e-0410-9357-904b9bb8a0f7

1 files changed, 53 insertions, 0 deletions

diff --git a/test-suite/ideal-features/evars_subst.v b/test-suite/ideal-features/evars_subst.v
new file mode 100644
index 000000000..6f9f86a95
--- /dev/null
+++ b/test-suite/ideal-features/evars_subst.v
@@ -0,0 +1,53 @@
+(* Bug report #932 *)
+(* Expected time < 1.00s *)
+
+(* Let n be the number of let-in. The complexity comes from the fact
+   that each implicit arguments of f was in a larger and larger
+   context. To compute the type of "let _ := f ?Tn 0 in f ?T 0", 
+   "f ?Tn 0" is substituted in the type of "f ?T 0" which is ?T. This
+   type is an evar instantiated on the n variables denoting the "f ?Ti 0".
+   One obtain "?T[1;...;n-1;f ?Tn[1;...;n-1] 0]". To compute the
+   type of "let _ := f ?Tn-1 0 in let _ := f ?Tn 0 in f ?T 0", another
+   substitution is done leading to 
+   "?T[1;...;n-2;f ?Tn[1;...;n-2] 0;f ?Tn[1;...;n-2;f ?Tn[1;...;n-2] 0] 0]"
+   and so on. At the end, we get a term of exponential size *)
+
+(* A way to cut the complexity could have been to remove the dependency in
+   anonymous variables in evars but this breaks intuitive behaviour
+   (see Case15.v); another approach could be to substitute lazily
+   and/or to simultaneously substitute let binders and evars *)
+
+Variable P : Set -> Set.
+Variable f : forall A : Set, A -> P A.
+
+Time Check
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+ 
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+  let _ := f _ 0 in
+
+    f _ 0.
+