CODEWITHSUNDEEP
if-statementprologflow-controllogical-purity
user 2345243512
user 2345243512

Reputation: 27

Proper flow control in Prolog without using the non-declarative if-then-else syntax

I would like to check for an arbitrary fact and do something if it is in the knowledge base and something else if it not, but without the ( I -> T ; E)syntax.

I have some facts in my knowledge base:

unexplored(1,1).
unexplored(2,1).
safe(1,1).

given an incomplete rule

foo:- safe(A,B),
% do something if unexplored(A,B) is in the knowledge base
% do something else if unexplored(A,B) is not in the knowledge base

What is the correct way to handle this, without doing it like this?

foo:-
   safe(A,B),
   ( unexplored(A,B) -> something ; something_else ).

Upvotes: 2

Views: 682

Answers (2)

user1812457
user1812457

Reputation:

Not an answer but too long for a comment.

"Flow control" is by definition not declarative. Changing the predicate database (the defined rules and facts) at run time is also not declarative: it introduces state to your program.

You should really consider very carefully if your "data" belongs to the database, or if you can keep it a data structure. But your question doesn't provide enough detail to be able to suggest anything.

You can however see this example of finding paths through a maze. In this solution, the database contains information about the problem that does not change. The search itself uses the simplest data structure, a list. The "flow control" if you want to call it this is implicit: it is just a side effect of Prolog looking for a proof. More importantly, you can argue about the program and what it does without taking into consideration the exact control flow (but you do take into consideration Prolog's resolution strategy).

Upvotes: 2

mat
mat

Reputation: 40768

The fundamental problem with this requirement is that it is non-monotonic:

Things that hold without this fact may suddenly fail to hold after adding such a fact.

This inherently runs counter to the important and desirable declarative property of monotonicity.

Declaratively, from adding facts, we expect to obtain at most an increase, never a decrease of the things that hold.

For this reason, your requirement is inherently linked to non-monotonic constructs like if-then-else, !/0 and setof/3.

A declarative way to reason about this is to entirely avoid checking properties of the knowledge base. Instead, focus on a clear description of the things that hold, using Prolog clauses to encode the knowledge.

In your case, it looks like you need to reason about states of some search problem. A declarative way to solve such tasks is to represent the state as a Prolog term, and write pure monotonic rules involving the state.

For example, let us say that a state S0 is related to state S if we explore a certain position Pos that was previously not explored:

state0_state(S0, S) :-
    select(Pos-unexplored, S0, S1),
    S = [Pos-explored|S1].

or shorter:

state0_state(S0, [Pos-explored|S1) :-
    select(Pos-unexplored, S0, S1).

I leave figuring out the state representation I am using here as an easy exercise. Notice the convenient naming convention of using S0, S1, ..., S to chain the different states.

This way, you encode explicit relations about Prolog terms that represent the state. Pure, monotonic, and works in all directions.

Upvotes: 1

Related Questions