Better errors with context

[UWN]

Two problems with errors

Insufficient information. The second argument of the error/2-term thrown in case of errors is an implementation defined term (7.12.1 The effect of an error) whereas the first argument is one out of the codified error classes in 7.12.2. Often, that error term is a bit too terse — think of an instantiation error which just tells you that some term in some argument of some predicate need to be instantiated further. But you neither know where this happens, nor do you get information of what type that instantiation shall be. Some built-ins at least leave their predicate indicator to take responsibility but then just the innermost place is reported. Think of

?- phrase((nt,1),L).
   error(type_error(callable,(nt(_614607,_614608),1)),(',')/2).

while the type error is perfect, the (',')/2 does not give any helpful hint. In some cases some more information is handed over already

?- phrase((a->b),L).
   error(representation_error(dcg_body),[culprit-(a->b)]).

So representation_error(dcg_body) is far too terse, the pair culprit-Culprit shows the actual culprit.

Complex encoding. To better influence this second argument, some of the error reporting facilities include an extra argument to be handed over in case of error (library(error)), making the regular code more complex with marginal gains in case of errors.

So the idea is to use a list of pairs and add a pair in case of an actual error.

:- meta_predicate(call_with_error_context(0,+)).
call_with_error_context(G_0, Pair) :-
   must_be(pair, Pair),
   catch(G_0, error(E,Pairs), throw(error(E,[Pair|Pairs]))).

Some keys of such pairs and their values may be:

culprit-Culprit the actual culprit — should it be representable as a term

predicate-PI this error occurs within a predicate whose predicate indicator is PI, like phrase/2. Note that it does not make sense to associate each and every predicate with such a context, but clean interfaces should do so

expected_type-Type the type of the insufficiently instantiated term

file-Filename

position-LineNr this would solve #302: The position prior to read/1-ing could be reported that way.

---

As a consequence, the errors of library(error) should be shortened to the actual error term, like

instantiation_error :-
   throw(error(instantiation_error,[])).

&ct.

A future better implementation might reduce overheads by identifying ground pairs at term-to-body conversion time and allocating them statically. Also, the actual goal G_0 might avoid being "globalized" thus retaining local variables. And, error-throwing might first identify the active catches and construct the list of pairs without more complex backtracking.

[bakaq]

For some reason I thought that you wanted to defer this improvement in errors to after the implementation of the rethrow optimization. So you now think this is beneficial enough to implement even before the optimization? I agree, because this will probably be the greatest improvement in the user experience of Scryer Prolog since the implementation of the toplevel, and it also aligns with Scryer's general philosophy of doing things well before doing them fast.

[UWN]

Or think of:

?- can_be(bot,L).
   error(type_error(type,bot),must_be/2), unexpected.
   type_error(type,bot). % this one is fine
   error(type_error(type,bot),...). % same more verbosely
   error(...,[predicate-can_be/2]). % expected, but not found

[triska]

This construct seems very valuable!

I filed #2846 to make it available in library(error), so that we can apply it in Scryer libraries.

[rotu]

Okay, so it looks like we're trying to fix issues like this (which are worse in deeply nested code):

?- atom_concat(1,2,S).
   error(type_error(atom,1),can_be/2).

The implementation looks like this:

atom_concat(Atom_1, Atom_2, Atom_12) :-
    error:can_be(atom, Atom_1),
    error:can_be(atom, Atom_2),
    error:can_be(atom, Atom_12),
    (  var(Atom_1) ->
    % ... actual logic here

How do I change this to use call_with_error_context so the error correctly says that this is a misuse of atom_concat?

[UWN]

atom_concat(Atom_1, Atom_2, Atom_12) :-
   call_with_error_context(atom_concat_i(Atom_1, Atom_2, Atom_12), predicate-atom_concat/3).

atom_concat_i(Atom_1, Atom_2, Atom_12) :-
    % as above

[rotu]

Thanks! It threw me off how "Pairs" could be a list when we haven't made changes to the throwers yet. But then I realized Prolog is perfectly happy to let you use | when the second operand is not a "proper" list :-).

atom_concat(Atom_1, Atom_2, Atom_12) :-
call_with_error_context(atom_concat_i(Atom_1, Atom_2, Atom_12), predicate-atom_concat/3).

Making that change more broadly involves duplicating all predicate declarations and repeating the PI inside every predicate body. Of course this can be done with term expansions or goal expansions but that too seems really messy.

Would it be crazy to make this part of loader:expand_call_goal or something similar?

[UWN]

This is only necessary for official interfaces. Making it too easy means that it will be used everywhere. And this is not meant as a programming construct.

But for the moment, everyone waits for the master/rebis-dev merger. Then wait until all error predicates in library(error) are clean (without the extra argument). There are much more important things than that. In particular partial strings (#24)

[rotu]

This is only necessary for official interfaces. Making it too easy means that it will be used everywhere. And this is not meant as a programming construct.

Okay. I'll assume there's a plan then and that any code rework will be narrowly confined to, e.g. builtins.pl and not throughout modules like clpz.

But for the moment, everyone waits for the master/rebis-dev merger.

👍 I'm happy to wait to merge. I don't expect to make any changes which will conflict, and I'm also happy to rebase or backmerge.

There are much more important things than that.

Big picture, yes. To the novice (me), error attribution, feature discoverability, and documentation gaps are intrusive and frustrating, so I'd like to fix them as I go!

If there are workarounds to error context (e.g. a goal_expansion I can put in my .scryerrc) I'd love to know.

Meanwhile, what would you have me work on that's important but not too esoteric?

[UWN]

Meanwhile, what would you have me work on that's important but not too esoteric?

Testing partial strings and their UTF-8 encodings. So yes, emojis serve a purpose.