Why Prolog Fits Expert Systems
Expert systems encode a domain expert's knowledge as facts and rules, then use an inference engine to derive conclusions from user-supplied observations. Prolog already ships with exactly this machinery: its clause database is the knowledge base, and SLD resolution is the inference engine. Writing an expert system in Prolog therefore means authoring the domain rules and letting the language's built-in search do the reasoning, rather than building a rule engine from scratch as you would in a general-purpose language.
Cricket analogy: It is like a stadium's Decision Review System already having ball-tracking rules built in for line calls, so applying those same rules to an LBW review needs no separate mechanism to be built.
Knowledge Representation: Facts and Rules
Facts are clauses with no body and represent unconditional domain data, such as symptom(patient1, fever). Rules are clauses with a body introduced by :-, combining conditions with conjunction (,) to represent diagnostic or inferential knowledge, such as concluding a disease when several symptoms co-occur. Multiple rules for the same head act as disjunction, so a query can succeed through any one of several diagnostic paths, and Prolog's backtracking will explore each in turn on demand.
Cricket analogy: A fact is like a scorecard entry saying Virat Kohli scored 82, while a rule is like the criteria for Man of the Match, combining runs, strike rate, and wickets taken.
% Facts: patient symptoms
symptom(patient1, fever).
symptom(patient1, cough).
symptom(patient1, rash).
% Rules: diagnostic knowledge
disease(Patient, measles) :-
symptom(Patient, fever),
symptom(Patient, cough),
symptom(Patient, rash).
disease(Patient, flu) :-
symptom(Patient, fever),
symptom(Patient, cough),
\+ symptom(Patient, rash).
?- disease(patient1, What).
% What = measles.Backward Chaining via SLD Resolution
Prolog's default execution strategy is backward chaining: given a goal, it works backward through matching rule heads, recursively trying to prove each subgoal against the clause database until it bottoms out at facts. This is precisely the inference strategy used by classic rule-based expert systems such as MYCIN, which started from a diagnostic hypothesis and searched for supporting evidence rather than deriving every possible conclusion from the facts up front.
Cricket analogy: It is like a captain reviewing an LBW by starting from the claim 'was it out?' and checking ball-tracking, impact, and pitching zone one at a time, rather than pre-computing every possible delivery outcome in advance.
Prolog has no built-in notion of uncertainty. Systems like MYCIN used numeric certainty factors to weigh conflicting evidence; a Prolog equivalent typically adds an extra argument to each rule to carry a confidence score, then combines those scores explicitly with arithmetic (is/2) inside the rule bodies, since there is no native probabilistic inference to fall back on.
Forward Chaining and Working Memory
Some expert system tasks are more naturally forward-chaining: start from known facts and fire applicable rules to derive new facts, repeating until no rule adds anything new. Prolog does not do this by default, but it can be simulated using assert/1 to add newly derived facts into the database and retract/1 to remove obsolete ones, effectively building a growing working memory that mirrors classic production-rule systems like OPS5.
Cricket analogy: It is like a scorer continuously updating the live match state, runs, wickets, and overs, ball by ball, building working memory of the innings rather than computing the final score directly from ball one.
Heavy use of assert/1 and retract/1 to simulate forward chaining introduces side effects that break Prolog's declarative purity. Clause order and timing start to matter, backtracking into a goal that already asserted facts can silently duplicate them, and there is no automatic truth maintenance to retract conclusions whose supporting facts were later removed. Use it deliberately and sparingly, and consider isolating dynamic state in its own module.
- Prolog's SLD resolution is inherently backward-chaining, matching classic expert system inference engines like MYCIN.
- Facts model unconditional domain data; rules combine conditions with :- and conjunction to model diagnostic knowledge.
- Multiple rule clauses for the same head act as disjunction, letting Prolog backtrack through alternative diagnoses.
- assert/1 and retract/1 can simulate forward chaining and working memory but sacrifice declarative purity.
- Certainty factors must be encoded manually as extra rule arguments since Prolog has no built-in uncertainty handling.
- Negation as failure (\+) is commonly used to express default diagnostic rules such as 'flu if no rash is present'.
- Cut (!) and careful rule ordering matter for controlling search when several diagnoses could otherwise match.
Practice what you learned
1. What execution strategy does Prolog's SLD resolution natively implement, matching classic expert system architecture?
2. In an expert system written in Prolog, which construct typically represents unconditional domain data?
3. Which built-in predicates are commonly used to simulate forward chaining and working memory in Prolog?
4. Why must certainty factors be added manually as extra rule arguments in Prolog expert systems?
5. What is a key risk of heavy assert/retract use in an otherwise declarative Prolog expert system?
Was this page helpful?
You May Also Like
Debugging Prolog Programs
Master Prolog's built-in tracer, spy points, and common failure patterns to systematically debug logic programs.
Prolog and AI Search Algorithms
See how classic AI search strategies, depth-first, breadth-first, and best-first, map onto Prolog's own backtracking engine and how to implement them explicitly.
Modules in Prolog
Learn how Prolog's module system namespaces predicates, controls visibility, and enables code reuse across larger logic programs.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics