/logic-programmer

name: logic-programmer
description: Logic programming thinking patterns and relational design principles. Use when working with logic languages (Prolog, miniKanren, Datalog, OWL2, Answer Set Programming) or applying declarative, constraint-based approaches in multi-paradigm systems.

Logic Programmer

Purpose

This skill provides guidance on logic programming thinking patterns and when relational, declarative approaches clarify problems. Logic programming expresses computation as logical inference over relations rather than procedural steps. This skill focuses on recognizing when problems are naturally relational, designing declarative specifications, and understanding the trade-offs of different logic programming approaches.

When to Use This Skill

Use this skill when:

• Working with logic languages (Prolog, miniKanren, Datalog, OWL2, Mercury, Answer Set Programming)
• Solving constraint satisfaction or combinatorial search problems
• Designing knowledge bases, ontologies, or inference systems
• Applying relational thinking to queries and pattern matching
• Recognizing when declarative specification clarifies over procedural algorithm

<core_philosophy>

Core Philosophy

<relational_thinking_decision>

Relational Thinking: When It Clarifies vs When It Obscures

Logic programming thinks in terms of relationships that must hold, not steps to execute. The key question: does relational thinking make the problem clearer?

**Relational thinking clarifies when:**

• Problem is naturally expressed as constraints (what must be true, not how to compute)
• Multiple computational directions needed (bidirectional relations)
• Specification is more important than algorithm (declarative rules)
• Querying relationships in structured data
• Generating multiple solutions from constraints

**Relational thinking obscures when:**

• Clear, efficient procedural algorithm exists
• Single computational direction suffices
• Stateful, imperative operations required
• Performance-critical numeric computation
• Procedural version is obviously simpler

**Staff insight:** Don't force problems into relational form. The power of logic programming is clarity through declarative specification. If the relational version is harder to understand than the procedural version, you're using the wrong paradigm. </relational_thinking_decision>

> "Algorithm = Logic + Control" — Robert Kowalski (1979)

An algorithm consists of logic (what to compute) and control (how to compute it). Ideal logic programming separates these; pragmatic logic programming often requires considering both.

<declarative_vs_procedural>

Declarative Specification Over Procedural Algorithm

Express what must be true, not how to compute it. Describe the problem constraints and let the system find solutions.

**Declarative thinking:**

• State facts and rules
• Define relationships and constraints
• Specify valid solutions
• Let inference engine/solver find them

**When declarative specifications win:**

• Problem is easier to specify than to solve algorithmically
• Multiple solving strategies could work (system can choose/optimize)
• Specification itself is valuable documentation
• Constraints change more often than solving strategy

**When procedural algorithms win:**

• Algorithm is well-understood and efficient
• Declarative version doesn't provide insight
• Performance matters and declarative overhead isn't justified
• System can't efficiently solve the declarative formulation

</declarative_vs_procedural>

<bidirectionality>

Bidirectionality as Design Opportunity

Relations can work in multiple computational directions. The same logical specification can answer different questions.

**Example:** `append(Xs, Ys, Zs)` defines relationship between three lists

• Forward: Given Xs and Ys, what is Zs?
• Backward: Given Zs, what are all ways to split into Xs and Ys?
• Checking: Does this (Xs, Ys, Zs) triple satisfy the relation?

**Design question:** Which computational directions are actually useful?

**Don't over-design:** Not all relations need to work in all directions. Design for modes you'll use. Document restrictions if they exist. </bidirectionality> </core_philosophy>

Fundamental Principles

Open vs Closed World Assumption

**Closed World Assumption (CWA):** What is not known to be true is false.

• Prolog, Datalog: If a fact isn't derivable, it's false
• Enables negation-as-failure
• Practical for databases and closed systems

**Open World Assumption (OWA):** Unknown is unknown, not false.

• OWL2, description logics: Absence of information means unknown
• Cannot conclude negatives from missing information
• Appropriate for incomplete knowledge (web, distributed systems)

**Design question:** What does absence of information mean in your domain?

Monotonic vs Non-Monotonic Reasoning

**Monotonic:** Adding facts never invalidates previous conclusions.

• First-order logic, Datalog, OWL2
• Conclusions remain valid as knowledge grows
• Reasoning is sound and complete within the logic

**Non-monotonic:** New facts can retract previous conclusions.

• Prolog with negation-as-failure
• Answer Set Programming (stable model semantics)
• Default reasoning, exceptions
• More flexible but more complex semantics

**Design question:** Does your domain require defaults and exceptions?

Declarative Semantics vs Operational Semantics

**Declarative semantics:** What the program means (logical interpretation)

• Independent of execution strategy
• Focus on correctness of specification
• Easier to reason about

**Operational/procedural semantics:** How the program executes

• Search strategy, evaluation order
• Performance characteristics
• Implementation-dependent

**Fully declarative systems:** Datalog, OWL2, Answer Set Programming separate logic from control

• Programmer specifies logic
• System chooses evaluation strategy
• Order doesn't affect meaning (only efficiency)

**Procedural systems:** Prolog, miniKanren require consideri