Improving catch/3

[UWN]

The control construct catch/3 introduces often a lot of inefficiencies such that it is rarely used. Maybe this situation can be improved. Here are some sources of inefficiencies for catch(mypred(A), error(type_error(_,_),_), false):

1. Expensive setup. The goal mypred(A) is copied onto the heap and thus if A was a local variable, that information is lost, executions is less efficient, in particular with set_prolog_flag(occurs_check, error)
2. Then the pattern to be caught must be copied, same unnecessary overhead
3. and some big choice point is created.
4. When the error occurs, the error term is unnecessarily copied.

All of this is not necessary for each and every use, but that's the way current implementations including Scryer do it.

As this is so expensive, some "less expensive" interfaces have been devised. Think of type_error(Type, Culprit, mypred/1) instead of type_error(Type, Culprit). This goes at the cost of clarity of code. One has to hand around a context that is not really interesting. Lots of code becomes unnecessarily dependent on the current representation of that argument.

Maybe it is possible to identify some use cases that do not need the full treatment of catch/3 and that can be implemented much more directly. I am thinking of

• replacing some kind of errors by failure (mostly domain, type, and syntax errors)
• rewriting the implementation defined part of error/2. Typically to indicate the "official" predicate responsible for the error.

The functionality of both could be defined as

:- meta_predicate(fail_catch(0,1)).
fail_catch(G_0, Pat_1) :-
   must_be(term, Pat_1),
   once(call(Pat_1, E)),
   catch(G_0, error(E,_), fail ).

:- meta_predicate(rewrite_catch(0,2)).
rewrite_catch(G_0, Rctx_2) :-
   must_be(term,Rctx_2),
   catch(G_0, error(E,Ctx), ( call(Rctx_2, Ctx, Ctx2), throw(error(E,Ctx2)) ) ).

But the point would be to implement this much more efficiently, by

• installing a much smaller handler
• not copying the goal onto the heap, just sticking within the WAM, even retaining registers
• looking at the pattern only in case of an actual throw/1
• already using the handles within throw/1-prior to copying the term, for fail_catch/2, that copy would never be needed
• no re-throwing in the case of rewrite_catch/2

[triska]

This sounds interesting! I remember many cases, especially when writing libraries, where I wanted to use must_be/2 or can_be/2, but then wrote custom code so that the relevant context (i.e., the library predicate) is shown in the exception. It would definitely be great to get this automatically, by having such a specialized mechanism insert the intended context (i.e., the library predicate where the exception arises) for us.

I now tried to find a concrete example where this could be useful, and I think one suitable case appears in library(time), where I "manually" throw a domain_error just so that sleep/1 appears as the context:

scryer-prolog/src/lib/time.pl

Line 73 in 6b8e620

domain_error(not_less_than_zero, T, sleep/1)

With the mechanism you propose, we could simply write all this as must_be(not_less_than_zero, T), is this correct? (Independently, I now noticed that the standard uses not_less_than_zero only for integers, and in this case it can also be a floating point number.)

Another example is from library(crypto):

scryer-prolog/src/lib/crypto.pl

Line 102 in 6b8e620

type_error(byte, B, Context)

This could simply be written as maplist(must_be(byte), Bytes), and the mechanism would automatically insert the invoked library predicate as context, is this the intended mechanism? So, in total, instead of:

must_be_bytes(Bytes, Context) :-
        must_be(list, Bytes),
        maplist(must_be(integer), Bytes),
        (   member(B, Bytes), \+ between(0, 255, B) ->
            type_error(byte, B, Context)
        ;   true
        ).

we would have:

must_be_bytes(Bytes) :-
        must_be(list, Bytes),
        maplist(must_be(byte), Bytes).

and Context need no longer be specified explicitly?

[UWN]

So there is an entry point where you now have some overhead which would be tiny if this would be supported accordingly. So say,

curve25519_scalar_mult(Scalar, Point, Result) :-
   rewrite_catch(curve25519_scalar_mult_ori(Scalar, Point, Result), rewrite(curve25519_scalar_mult/3)).

where rewrite(curve25519_scalar_mult/3) may be a global ground term so not even that requires extra space.

When this is effectively compiled there is only a tiny overhead for setting up the handler.

In case of an exception this calls call(rewrite(curve25519_scalar_mult/3), OriginalContext, NewContext). So also the instantiation error of integer_si/1 gets a better context. Note that currently there is just the predicate indicator, but that might get much more complex in the future, maybe like the association lists of IF/Prolog. Also, stacking up the different contexts would be possible. It is all up to this rewrite/3.