Distinguish failure to match head from other fault

[hurufu]

Consider the following (trivial) code:

foo(a(X)) :- bar(X).
foo(b(X)) :- baz(X).

and the following query:

?- foo(c(X)).

What is the best/recommended way to distinguish failure to match head of a goal from other fault? I commonly tag my variables with "types" for example: report(employee(X)) instead of just report(X).

There is a common pattern:

foo(a(X)) :- !, bar(X).
foo(b(X)) :- !, baz(X).
foo(Y) :- throw(error(domain_error(unmatched_head,Y),_)).

Or some variations of it. I find it quite inelegant, because I need to modify every foo predicate. Is there a more generic approach? I think of a higher order predicate like must_match(foo(c(X))) that will inspect the clause body and do the same... But maybe there is something written already.

[UWN]

It all depends on what your predicate is about. Is it truly relational? Then go along library(error) must_be/2 and can_be/2.
Currently, your common pattern misses an instantiation error, as ?- foo(G). just sticks to the first clause.

If you issue a domain error, the first argument should be the domain not the observed problem. In general it is better to state with the error what is expected and less what is 'the problem'. See the error classification on how errors are formulated in ISO.

[hurufu]

Ok, so if I understand you correctly a better approach would be:

foo(Y) :-
    free_variable_or_good_shape(Y),
    foo_(Y).

foo_(a(X)) :- bar(X).
foo_(b(X)) :- baz(X).

Indeed it is also clear, but sadly I still need auxiliary predicate... I imagine it would be nice if Prolog runtime could've detect this situation automagically something akin to:

:- exhaustive_definition foo/1
foo(a(X)) :- bar(X).
foo(b(X)) :- baz(X).

P.S. Thanks for a link to error classification, here I just wanted to show the overall concept, without much thinking about correctness, because I found similar code in quite a few places. That's why I called in a "common pattern".

[hurufu]

I wrote a little proof-of concept of what I imagine it might look like, most code is in error reporting you can ignore it:

head_must_match(G) :-
    \+ clause(G, _) -> head_match_error(G); call(G).

head_match_error(G) :-
    functor(G, Functor, Arity),
    length(Args, Arity),
    Fresh =.. [Functor|Args],
    findall(Fresh, clause(Fresh,_), Heads),
    throw(error(domain_error(oneof(Heads),G),_)).

:- dynamic([foo/1]).
foo(a(X)) :- bar(X).
foo(b(X)) :- baz(X).

bar(1). bar(2). baz(a).

The following query succeeds:

?- head_must_match(foo(a(X))).

And the next correctly throws an exception:

?- head_must_match(foo(c(X))).

Big problem is that it works only with dynamic predicates, that's why I was talking about something "automagical".

[UWN]

Minor remark: replace above length(Args, Arity), Fresh =.. [Functor|Args] by functor(Fresh, Functor, Arity). No need for Args.

Next minor remark: what happens with duplicates?

In general, domains and types are often seen as quite fundamental constructs that are documented independently of a specific predicate. What you suggest is to produce such domains on the fly which is quite ephemeral. If you really want to construct such a domain, call it one_of/1 as suggested in the note of 5.5.9.

[hurufu]

Thanks, for your remarks. I think the topic was discussed exhaustively.

[haijinSk]

As a beginner, I do not use the cut (!), more, my understanding of the Prolog cut operator is only vague, mostly like this: do not use it, if you want declarative programming.

But, If I have to distinguish and really explicitly report to the user (me) the "unmatched head case" then...

Then, as @UWN wrote: it all depends... But, anyway, with one very strict/hard assumption, I see something like this:

% Assume!!!: an argument to foo/1 has always shape like this: something(something)
foo(a(X)) :- bar(X).
foo(b(X)) :- baz(X).
foo(Y) :- reporting(Y).  

% Only "raw & brutal" printing here
reporting(Case) :- 
  format("Unmatched head: ~q~n",[Case]).

I know... I see you, the thumb down...

[UWN]

For cuts, see this. Roughly, a cut without a clean guard is probably misplaced.

Note that before ?- foo(42). failed silently. And now, you will get that printout for every goal upon backtracking.

Reporting errors just by printing things out leads to lots of messages flushing over the screen. But the program will continue to do evil things. In case you really do not want to spend the time to ponder about the various error classes, just issue a system error with some message like:

?- throw(error(system_error, 'Bad, bad...')).

[haijinSk]

Thank you very much for the response...

[haijinSk]

Maybe, in other words, as a beginner, I didn't understand why the cuts, if every case/clause has a different "type tag", like in the example: a/1, b/1. Or, I see Prolog without the cut as effective enough, especially if every case is discriminated in heads of clauses. At least, as I want to see it... And I want to see it as a declarative programming language and as a language for (inductive) definitions more than a conventional programming language with a different syntax.

[hurufu]

At least in my case, when I write a library predicate I don't know beforehand how my predicates will be used, that's why I try to detect as many errors as possible in publicly visible predicates. Also I think that throwing an exception is much-much more helpful than silently fail and print false. In my example cuts were needed to avoid calling last "catch-all" definition.

[haijinSk]

@hurufu Thank you very much for the explanation, I saw it from the point of view where one can "control/arrange" everything before the program is running, where the one is the author and user of the code...

[hurufu]

Why I started this seemingly trivial topic is because it is actually a major pain point for writing programs of any substantial size. Prolog has so much potential to analyze your code for errors, but in the end I need to validate predicate parameters at runtime like in JavaScript. I feel that there is a more elegant solution...

[UWN]

This topic is not trivial and it took Prolog quite some time to come to terms with it. In the past (primiarily in the 1980s) many systems failed in case of an erroneous situation which often leads to hard-to-debug errors. A good example why it is so important to handle errors explicitly is clpz:labeling/2. There, failure should mean: there is no solution to the constraint problem, and it would be disastrous to fail for an unknown or invalid labeling option. library(error)'s must_be/2 and can_be/2 are a good starting point.

[triska]

How do these unintended failures happen in the cases you mean? Do they arise for example when one mistypes a goal in a predicate? In such cases, for pure monotonic programs, you can use (*)/1 from library(debug) to generalize the program by placing * in front of a goal. If the resulting fragment still fails unintendedly, then there is a mistake in the remaining fragment. This analysis can be automated and explain unintended failures by showing smallest program fragments, requiring no changes in the application code.

[UWN]

Here is a collection of debugging examples mostly using *

[hurufu]

Yes it sounds good, and indeed should be the main way to debug Prolog programs, but declarative debugging isn't something I'm fluent with, I still rely on write and trace in most cases.

[UWN]

Every action you do will slightly influence your future thinking. So when you attempt to debug Prolog programs in a step-by-step fashion this will reinforce a step-by-step, do-this, do-that thinking. But for most programs you do not need all procedural details to understand the relevant part of them. Though some procedural details are relevant. Most prominently termination. Even in that situation you can use a failure-slice to narrow down the code where you do have to understand its procedural meaning.

At least use portray_clause/1 or writeq/1 in place of write/1. Or even better $/1.