summarizing recent advice on learning/teaching Prolog

[mvolkmann]

This is my attempt to summarize the advice I have been given through multiple questions here, mostly by @triska and @UWN. Feel free to correct anything I say here.

When someone is first learning Prolog they should focus only on the parts in the pure monotonic core. These include true/0, false/0, fail/0, unify_with_occurs_check/2, (=)/2, (','), (;), and custom predicates that only use these.

The reason to restrict oneself to only these parts of Prolog is to deeply learn about termination (stop searching for more solutions), choicepoints (alternatives to consider), and supporting the most general queries (all arguments are variables).

Ideal Prolog predicates have the following characteristics:

• finds all valid solutions and does not find any invalid solutions
• always terminate when there is not an infinite number of solutions
• never leaves choicepoints after the last solution is found
• can be invoked with all arguments being variables (most general query)

The focus at this stage of learning is not to write applications for others to use. It is on learning how to write good Prolog code. If this is not learned early on, developers are likely to undervalue the characteristics of good predicates. They will be more likely to implement custom predicates that have issues with termination and choice points, and do not support the most general query. Therefore they will not fully benefit from the strengths of Prolog.

Prolog predicates can be divided into three categories, those that are always pure, those that can be pure when used in specific ways, and those that are never pure (and should be avoided). An example of the last category is the -> operator.

The following is a list of Prolog topics that should not be considered until the lessons above are learned:

• running Prolog code in source files (just use top-level for now)
• nearly everything that is not defined in the ISO standard
• any operators not in the pure monotonic core (includes arithmetic operators and creating custom operators)
• working with numbers
• working with strings
• working with lists (the list constructor is not included in the pure monotonic core)
• working with pairs
• working with assoc
• compiler directives like set_prolog_flag, include, use_module, and initialization
• debugging with trace
• implementing unit tests
• knowledge base changes with dynamic, asserta, assertz, retract, and retractall
• using [user]. to dynamically add predicates in a top level
• obtaining input from the keyboard, a file, or a network connection (includes get_line_to_chars and read_term)
• creating output to the terminal, a file, or a network connection (includes write and format)
• Constraint Logic Programming (CLP)
• Definite Clause Grammars (DCG)
• unfair enumeration and iterative deepening
• puzzle solutions like the jugs problem, zebra puzzle, Einstein's Riddle, and Sudoku
• invoking Prolog queries from other languages (or an HTTP server) and obtaining solutions

When I give a talk on Prolog, I'm concerned that if I follow all of this advice then I will not tell the audience enough to pique their interest and make them want to learn Prolog. The list above includes topics I think are important to cover in order to make developers want to learn more about Prolog.

[pmoura]

As always when doing a presentation, knowing the audience is key... what you describe could work (or be suitable) for students taking a course in logic programming for a computer science degree. But for developers versed in other programming languages and curious about logic programming in general and Prolog in particular? I share your doubts.

[mvolkmann]

My audience will be developers with a large amount of experience in other languages.

[pmoura]

A good question is: what are those developers pain points in other programming languages that could successfully be addressed with logic programming?

[UWN]

This looks much better!

clpz and DCGs, unfair enumeration, iterative deepening, the zebra puzzle (not that I think this is the best to start with), numbers (although best is still to start with successor arithmetics), lists and strings (that is "abc" = [a,b,c]), pairs, all fit into the pure, monotonic part too. So you can already write some non-trivial programs in particular with parsing and scheduling.

Also note that taking this approach isn't that new. Books like The Art of Prolog of 1986 suggested it as well. The main difference is that in the meantime there are better reading techniques to understand unexpected success, failure, and non-termination. Mastery of these is important. And yes, interaction with the top level is key for this pure part.

Other parts like the if-then-else -> are better left to a later moment, even if it works ok with conditions that ensure their own sufficient instantiation.

And for side-effecting built-ins, like I/O and database manipulation. Of course you need them, but using them right from the very beginning will obstruct the essence of the language.

(As minor remarks, note that terms are certainly part of the pure, monotonic core. And in a course there is no need for fail, nor unify_with_occurs_check/2 provided you use Scryer or SWI that permit to run with sound unification.)

[mvolkmann]

I have the books "The Art of Prolog" and "Programming in Prolog - Fifth Edition" from Clocksin and Mellish. My next task is to read through those.

[UWN]

Here is a tutorial on teaching Prolog (ICLP 1997), and an older one with slides (PAP 1995).

[triska]

It is also worth knowing why "there is no need for fail/0": That's because as of Technical Corrigendum 2, i.e., since 2012, false/0 is part of the Prolog standard. "False" is the declarative opposite of "true", and hence preferable over the procedurally named "fail". The procedural opposite of "fail" would be "succeed", and "succeed" is not part of the standard. It would seem strange to use "succeed" instead of "true", yet replacing "fail" by its declarative equivalent "false" in Prolog courses and teaching material will take many decades. This is an example of the adoption of more declarative predicates, and shows how long it will take. false/0 is useful for example in failure slices, and also occurs in answers of the Scryer Prolog toplevel.

A nice classification of pure predicates was recently posted and is available from https://old.reddit.com/r/prolog/comments/10nuwz8/what_exactly_is_the_pure_monotonic_core_of_prolog/. clpz constraints (in the monotonic execution mode), dif/2 and DCGs are contained in this list and are already available in many Prolog systems, even though they are not yet part of the standard.

Note that choicepoints were not mentioned in any of the recent discussions, and they reside on a completely different level from program correctness and this discussion about the monotonic core of Prolog. A Prolog implementation may create or eliminate choice points depending on its indexing strategy, program analysis etc., and indeed newer versions of Scryer Prolog already provide much improved indexing and eliminate many choicepoints that earlier versions kept pending.

[aarroyoc]

In late 2022 I did a talk at my company too about Scryer Prolog. However, it wasn't an introduction to Prolog. Instead, I just went with Constraint Programming problems and how to solve them (as that is what I was more interested in at that time) using Scryer Prolog. I took a lot of examples from the book "Constraint Solving and Planning with Picat" but I translated the problems.

You can see the slides here: https://docs.google.com/presentation/d/e/2PACX-1vSEIZq4s_DMe3ejtp_OQ7JQpXktbgeDQCaonArxkirCL7RB9u3ZPo1FvsHppncvrrecLJmV2qEJod5s/embed?start=false

And a recording of that talk (in Spanish): https://www.youtube.com/watch?v=c_yP_kr7DxI

[triska]

One additional point that may be worth knowing when teaching Prolog and strings which you mention: All recent Prolog systems (Scryer, Tau, Trealla and ichiban/prolog) set the Prolog flag double_quotes to chars by default. This means that double-quoted strings are represented as lists of characters in these systems. Due to the readability advantage of characters over codes, chars is also the most likely default value in future Prolog systems.

I mention this also because I saw a post in which it is argued that using chars is a bad idea when using DCGs, because it "seems to break the functionality of the predicates defined in the dcg/basics library" which is specific to SWI. As I see it, given that lists of characters are the representation of strings in Prolog with the most advantages, libraries should support this representation.

Scryer Prolog uses a very compact internal representation of strings, and DCGs allow very convenient reasoning about strings. It is clear that any potential string library for Scryer and other modern Prolog systems must be able to work on this representation of strings as lists of characters.