More detailed error messages

[dougransom]

I admit I get quite baffled when I see some of the errors reported, but to be fair I spend little time trying to learn myself prolog.

In the roadmap, for Phase 2 consider adding something like
"Detailed Error Reporting for New Prolog Programmers".

I do think participants in an introductory course in programming should be deliverable in prolog (as opposed to java or pascal) but students might need more help in identifying errors (I know I do).

[aarroyoc]

I agree that errors could be better, by better detecting the error condition (sometimes the error comes from other place) and by giving more descriptive names. However, I think it's interesting to preserve how errors are formulated.

Right now, Prolog errors are valid Prolog syntax! Which is a nice property for metaprogramming. Other programming languages generate more verbose errors that may be easier to understand to learners, but that error is challenging to parse by another program.

[bakaq]

I haven't thought about using comments like this, this enables getting the best of both worlds. I imagine something like this:

?- failing_predicate.
   % Comment with user friendly representation of error and info.
   error(some_error(a,b,c), really_long_term_with_machine_usable_info(a,b,c,d,e,f,g,h,i,j,k)).

This also makes me think, should we put warnings in comments also? Currently they are not (necessarily) valid Prolog terms:

% Current behavior
?- [user].
a(A).
Warning: singleton variables A at line 1 of user

% Better behavior?
?- [user].
a(A).
% Warning: singleton variables A at line 1 of user

Even the Github syntax highlighting gets all messed up after a warning.

[triska]

Personally, I think yes: Warnings should be emitted as Prolog comments.

[infogulch]

Using comments for human friendly formatted output, or more generally for all output that is not parsable as a valid prolog term, is a great idea.

Edit to clarify: all output printed by the top level itself should be valid prolog terms or comments (which are valid prolog terms). Of course output printed by the user shouldn't be altered.

[triska]

time/1 also uses this idea:

?- time(true).
   % CPU time: 0.000s, -22 inference (exception?)
   true.

[dougransom]

This seems like a big task to improve error messages with a lot of considerations, which is why I am suggesting a line be added to the roadmap. To make scryer more friendly for beginners.

[infogulch]

I think errors should include file and line information, in addition to details like relevant variable names and values. See #2195

[UWN]

Before adding contextual information like file, line number, or the predicate indicator of the intended interface predicate, the catch/3 and throw/1 mechanism needs to be optimized for such use cases. Otherwise code gets cluttered with ad hoc contexts. To a certain degree we have this already, think of the extra last argument in library(error) of instantiation_error/1, domain_error/3 and type_error/3 which cannot add much valuable information anyway, they just clutter code as is illustrated by their use in must_be/2.

[bakaq]

What you are saying here is that there should be special handling for the second argument of error/2 in catch/3 and throw/1, such that the information is handled better? Wouldn't this be going beyond the ISO standard, or is this an allowable extension? But I can indeed see why this would be necessary, so that we could display a backtrace or at least give the line number on the file the user is writing, not in the file 80 calls down where the error was thrown.

[UWN]

This is not about changing anything in the standard. At least so far. It is about an efficient implementation for cases that do not exploit the full functionality of catch/3. Look at terms:numbervars/3, this catch/3 there is currently extremely expensive.

One source of it being expensive is that the goal has to be copied onto the heap and thus all precious local variables become sluggish heapvariables. If the Recovery just re-throws the error with some marginal modifications, the mechanism could be much cheaper for such cases. Also note that such context information is rarely used, only in the unlikely case of an error, but for most cases no error is thrown and optimizing for that regular case could change the cost significantly.

So the idea would be to have somehow a specialized version of catch/3, that executes the goal with almost no overhead and performs on recovery only some very simple operations like adding some additional context and rethrowing the error which means that no choicepoint has to be saved. Effectively the original throw/1 reads that entry (and all the other entries that are not a full catch) and modifies the error term accordingly.

[UWN]

One possibility would be to adopt the scheme of IF/Prolog mentioned here.

So the second argument of error would be a list of pairs (or a list of equals as IF does). [] if nothing of interest is to be said. So this would stop the usage of variables for this situation. Particular callers that form some interface would add their own information simply by adding a further element (at the beginning of the list, indeed).

The situation where this came up again was this. It would have helped a lot if the representation_error(dcg_body) would have been accompanied by information about the culprit, and maybe even the file position, or the entire read-term.