Callback Actions for Exceptions and Failure
Posted: 21 May 2015 14:56
Hello Thomas,
for some purposes it could be very beneficial, if callback predicates could be set, which are called
a) whenever an exception occurs,
b) whenever something has failed, i.e. each time backtracking has been performed.
The purpose, for which I would like to use the callback predicates, is (I talked about it already in earlier posts): By such callback predicates it would become possible to code a determ unify predicate (you described the unify predicate in tutorial How To Remove Reference Domains from a Project). Currently the unify predicate must be nondeterm to accomplish releasing bindings when backtracking takes place. A nondeterm unify predicate however has the huge drawback, that cuts cannot be used anymore in places, where it also would cut off a backtrack point from the unify predicate. The problem applies also to the implicite cuts in list comprehension, if-then-else, and foreach.
To not fall into an endless loop, the callback predicate of a) should not be called on exceptions, which occur in itself, resp. the predicate of b) should not be called, when something fails in itself.
Can you pleeease consider implementing a way programmers can set such callback predicates in a future VIP version?
Best regards
Martin
for some purposes it could be very beneficial, if callback predicates could be set, which are called
a) whenever an exception occurs,
b) whenever something has failed, i.e. each time backtracking has been performed.
The purpose, for which I would like to use the callback predicates, is (I talked about it already in earlier posts): By such callback predicates it would become possible to code a determ unify predicate (you described the unify predicate in tutorial How To Remove Reference Domains from a Project). Currently the unify predicate must be nondeterm to accomplish releasing bindings when backtracking takes place. A nondeterm unify predicate however has the huge drawback, that cuts cannot be used anymore in places, where it also would cut off a backtrack point from the unify predicate. The problem applies also to the implicite cuts in list comprehension, if-then-else, and foreach.
To not fall into an endless loop, the callback predicate of a) should not be called on exceptions, which occur in itself, resp. the predicate of b) should not be called, when something fails in itself.
Can you pleeease consider implementing a way programmers can set such callback predicates in a future VIP version?
Best regards
Martin