[jodrellblank]

Here's an infinite loop in Prolog, getting the length of a list:

    length(List_of_animals, Len)

Oops, List_of_animals hasn't been bound to any value, so length/2 will backtrack forever making it a longer and longer list of empty placeholders. Nothing will warn you that the variable wasn't declared because that's also a normal thing to do. Here's another, checking if something is in a list:

    member(cat, List_of_animals)

same problem, if the list isn't grounded to a fixed length list by the time this line executes, backtracking will generate longer and longer lists with `cat` in them and lots of placeholders:

    [cat]
    [_, cat]
    [_, _, cat]
    ...

forever. It's not just that you can accidentally write an infinite for(;;) loop by typoing the exit condition, it's that a lot of things in Prolog can be used in ways which finish deterministically or in ways that act a bit like Python generators yielding endless answers. So it's about the context in which you call them, and the surrounding code. e.g. one reason you're using Prolog is that you want it to generate List_of_animals for you (making up fictional animal names, or something), so you can't look for a missing `List_of_animals = [...]` because there might not be one anywhere.

[derdi]

> Nothing will warn you that the variable wasn't declared because that's also a normal thing to do.

Minor nitpick regarding an otherwise good answer: Prolog systems will warn you about "singleton variables", that is, variables with exactly one occurrence. This does catch the usual cases of this kind of error.

[YeGoblynQueenne]

The OP is asking whether that is an issue "in practice" and then points out the rarity of infinite loops "in production in the backend" [1].

For me, while that kind of thing gets me once in a while it never makes it to my final commits. That's because I always test every predicate I add to a program in isolation. Hey, sometimes I even write unit tests! So my experience is that the ability to write and test your program in sizeable chunks makes up for the danger of unbound variables causing infinite loops, in practice.

Also note that some Prologs have helpful error messages that direct the user to the problem. E.g. in SWI-Prolog (in "debug" mode):

  [debug]  ?- findall(cat,member(cat,List_of_animals),Cats).
  ERROR: Stack limit (1.0Gb) exceeded
  ERROR:   Stack sizes: local: 71Kb, global: 0.9Gb, trail: 3Kb
  ERROR:   Stack depth: 417, last-call: 0%, Choice points: 415
  ERROR:   Possible non-terminating recursion:
  ERROR:     [417] lists:member_(_230090210, cat, _230090214)
  ERROR:     [416] lists:member_([length:1|_230090242], cat, _230090236)
  ^  Exception: (4) setup_call_cleanup('$toplevel':notrace(call_repl_loop_hook(begin, 0)),   $toplevel':'$query_loop'(0), '$toplevel':notrace(call_repl_loop_hook(end, 0))) ? creep

Note:

  ERROR:   Possible non-terminating recursion:
  ERROR:     [417] lists:member_(_230090210, cat, _230090214)

_________________________

[1] I remember two infinite loops in production, one in the backend, one in the frontend. That was ca. 2013 so more than 10 years ago- good estimate!

The first loop was a missing terminating condition in a for-loop in C# that brought down the company's server along with every client's deployment (it was before everyone moved all their data to the cloud, you see). There was a meeting Upstairs™ and the programming team lead returned to tell us that he had explained what happened, explained that it was nobody's fault and that there's no way to prevent infinite loops like that happening again with perfect certainty, and that Upstairs had decided that, henceforth, iteration should no longer be used and when loops are required recursion should be used instead. Obviously that was completely ignored and everyone carried on as before.

The second loop was a bona-fide recursion without a terminating condition that happened in an in-house, Jango-like, templating language, called Mango. I don't remember the details but the folks who had coded the Mango interpreter evidently did a good job because it had no problem interpreting a recursive call in a template. The programming team lead from the previous story found it in a late-afternoon session where it was just me and him in the room. I felt a little deflated but I was just a junior starting out so I guess I was excused for missing it.