@@ -300,9 +300,6 @@ impl<C: Context> Forest<C> {
300
300
// subgoals may be eligble to be pursued again.
301
301
ex_clause. answer_time . increment ( ) ;
302
302
303
- // Apply answer abstraction.
304
- self . truncate_returned ( ex_clause, infer) ;
305
-
306
303
// Ok, we've applied the answer to this Strand.
307
304
return Ok ( ( ) ) ;
308
305
}
@@ -1038,6 +1035,28 @@ impl<C: Context> Forest<C> {
1038
1035
assert ! ( subgoals. is_empty( ) ) ;
1039
1036
assert ! ( floundered_subgoals. is_empty( ) ) ;
1040
1037
1038
+ // If the answer gets too large, mark the table as floundered.
1039
+ // This is the *most conservative* course. There are a few alternatives:
1040
+ // 1) Replace the answer with a truncated version of it. (This was done
1041
+ // previously, but turned out to be more complicated than we wanted and
1042
+ // and a source of multiple bugs.)
1043
+ // 2) Mark this *strand* as floundered. We don't currently have a mechanism
1044
+ // for this (only floundered subgoals), so implementing this is more
1045
+ // difficult because we don't want to just *remove* this strand from the
1046
+ // table, because that might make the table give `NoMoreSolutions`, which
1047
+ // is *wrong*.
1048
+ // 3) Do something fancy with delayed subgoals, effectively delayed the
1049
+ // truncated bits to a different strand (and a more "refined" answer).
1050
+ // (This one probably needs more thought, but is here for "completeness")
1051
+ //
1052
+ // Ultimately, the current decision to flounder the entire table mostly boils
1053
+ // down to "it works as we expect for the current tests". And, we likely don't
1054
+ // even *need* the added complexity just for potentially more answers.
1055
+ if infer. truncate_answer ( & subst) . is_some ( ) {
1056
+ self . tables [ table] . mark_floundered ( ) ;
1057
+ return None ;
1058
+ }
1059
+
1041
1060
let subst = infer. canonicalize_answer_subst ( subst, constraints, delayed_subgoals) ;
1042
1061
debug ! ( "answer: table={:?}, subst={:?}" , table, subst) ;
1043
1062
@@ -1456,50 +1475,4 @@ impl<C: Context> Forest<C> {
1456
1475
} ) ;
1457
1476
debug ! ( "flounder_subgoal: ex_clause={:#?}" , ex_clause) ;
1458
1477
}
1459
-
1460
- /// Used whenever we process an answer (whether new or cached) on
1461
- /// a positive edge (the SLG POSITIVE RETURN operation). Truncates
1462
- /// the resolvent (or factor) if it has grown too large.
1463
- fn truncate_returned ( & self , ex_clause : & mut ExClause < C > , infer : & mut dyn InferenceTable < C > ) {
1464
- // DIVERGENCE
1465
- //
1466
- // In the original RR paper, truncation is only applied
1467
- // when the result of resolution is a new answer (i.e.,
1468
- // `ex_clause.subgoals.is_empty()`). I've chosen to be
1469
- // more aggressive here, precisely because or our extended
1470
- // semantics for unification. In particular, unification
1471
- // can insert new goals, so I fear that positive feedback
1472
- // loops could still run indefinitely in the original
1473
- // formulation. I would like to revise our unification
1474
- // mechanism to avoid that problem, in which case this could
1475
- // be tightened up to be more like the original RR paper.
1476
- //
1477
- // Still, I *believe* this more aggressive approx. should
1478
- // not interfere with any of the properties of the
1479
- // original paper. In particular, applying truncation only
1480
- // when the resolvent has no subgoals seems like it is
1481
- // aimed at giving us more times to eliminate this
1482
- // ambiguous answer.
1483
-
1484
- match infer. truncate_answer ( & ex_clause. subst ) {
1485
- // No need to truncate
1486
- None => { }
1487
-
1488
- // Resolvent got too large. Have to introduce approximation.
1489
- Some ( truncated_subst) => {
1490
- mem:: replace (
1491
- ex_clause,
1492
- ExClause {
1493
- subst : truncated_subst,
1494
- ambiguous : true ,
1495
- constraints : vec ! [ ] ,
1496
- subgoals : vec ! [ ] ,
1497
- delayed_subgoals : vec ! [ ] ,
1498
- answer_time : TimeStamp :: default ( ) ,
1499
- floundered_subgoals : vec ! [ ] ,
1500
- } ,
1501
- ) ;
1502
- }
1503
- }
1504
- }
1505
1478
}
0 commit comments