prolog.org

Prolog Philosophy and Best Practices

Pure Predicates and Referential Transparency

Focus on the referentially transparent, pure predicates.

Delight in unification and backtracking.

Rejoice in logical domain modelling relations.

Trust the Prolog inference engine to handle execution.

Use cuts sparingly, and only when necessary.

Prefer if-then-else constructs (->;) for deterministic choices.

Write Reversible Predicates

Aim for predicates that can be used for both testing and generating solutions.

Use logical variables to create flexible, multi-purpose predicates.

Avoid unnecessary instantiation checks that limit predicate reversibility.

Separate Logic from I/O

Implement the main logic using pure predicates.

Use wrapper predicates for handling I/O and other side effects.

This separation enhances testability and maintainability.

Use Meta-programming Capabilities

Employ call/1-N for higher-order programming.

Use term expansion for code generation when appropriate.

Delight in Prolog’s ability to treat code as data.

Descriptive Predicate Names

A good predicate name makes clear what the predicate arguments mean.

Ideally, a predicate can be used in all directions, and its name should reflect this generality.

Examples of good predicate names:

• list_length/2: relating a list to its length
• integer_successor/2: relating an integer to its successor
• student_course_grade/3: relating students to courses and grades

The Virtues of Pure Code

Pure code in Prolog is a paragon of logical clarity and flexibility. It empowers us to write concise, general specifications that yield compact yet powerful programs. With pure predicates, we can:

• Explore solutions through general queries, unveiling the full spectrum of possibilities our logic encapsulates.
• Refactor with confidence, reordering goals and clauses to optimize performance without altering the program’s semantic essence.
• Reason declaratively about our code, understanding how constraints shape the solution space.
• Craft elegant test cases using nothing more than Prolog queries.
• Achieve inherent thread safety, sidestepping the pitfalls of data races in our increasingly concurrent world.

Exceptions and Errors

Prolog’s exception handling mechanism is a powerful tool for managing exceptional situations. The ISO standard defines several types of exceptions:

• Type error: Raised when a term of a specific type is expected, but a different type is present. The ISO standard defines specific term sets (e.g., integer, list) for which type errors may be raised.
• Domain error: Similar to a type error, but for expected term types not predefined in the standard.
• Instantiation error: Occurs when a predicate argument is insufficiently instantiated (i.e., a variable where a more specific term is expected).

There’s a crucial semantic distinction between these exceptions:

• Type and domain errors can be replaced by silent failure declaratively, as no additional constraints can turn such situations into success.
• Instantiation errors must not be replaced by silent failure, as there could still be solutions, and adding constraints may reveal them.

Exceptions are often more useful than silent failure in exceptional situations, as they provide insight into the problem’s cause.

Use Pure Arithmetic

Prolog offers powerful capabilities for reasoning about integers through CLP(FD) (Constraint Logic Programming over Finite Domains) or CLP(ℤ) constraints. These constraints provide a pure and declarative approach to integer arithmetic, superseding older, impure methods.

The Power of CLP(FD) Constraints

CLP(FD) constraints allow us to:

• Reason about integers in a pure and declarative manner.
• Use arithmetic relations in all directions, not just for evaluation.
• Automatically propagate constraints, narrowing variable domains.
• Separate problem modeling from the search for solutions.
• Express complex arithmetic relations succinctly and clearly.

Key CLP(FD) Predicates

The most important CLP(FD) constraints for integer arithmetic are:

• (#=)/2 : Equality
• (#<)/2 : Less than
• (#>)/2 : Greater than
• (#\=)/2 : Not equal
• (in)/2 : Domain specification
• (ins)/2 : Domain specification for lists of variables

Benefits Over Legacy Predicates

CLP(FD) constraints offer several advantages over older arithmetic predicates like (is)/2 and (>)/2:

1. Bidirectionality: CLP(FD) constraints work in all directions, unlike moded predicates that only work in specific instantiation patterns.
2. Clear intent: They make it explicit that you’re reasoning about integers, not floating-point or rational numbers.
3. Easier debugging: Type errors are raised instead of silent failures, helping to catch certain classes of mistakes more easily.
4. Simpler semantics: Beginners can focus on declarative meaning without needing to understand Prolog’s procedural execution model.
5. Unified representation: (#=)/2 subsumes both (is)/2 and (:)/2 for integer reasoning, simplifying the language.

Best Practices

1. Use CLP(FD) constraints for all integer arithmetic in your programs.
2. Prefer (#=)/2 over (is)/2 and (:)/2 when working with integers.
3. Use (in)/2 and (ins)/2 to specify domains for variables, enabling constraint propagation.
4. Separate problem modeling (using constraints) from solution search (using labeling).
5. Consider using labeling strategies like first-fail (ff) for efficient search when needed.
6. Be aware of the trade-off between constraint propagation strength and efficiency, choosing appropriate constraints for your problem.

By embracing CLP(FD) constraints, we can write more declarative, flexible, and powerful Prolog programs for integer arithmetic reasoning.