Authorization is one use case, e.g.,

"Can this user do this thing given these constraints?" or even "Show me all the things this user can do given these constraints"

Our team is solving for this use case. While we focus a lot on abstractions, APIs, etc. that are appropriate for our use case, under the hood everything is driven by an embeddable logic language that we write in Rust, called Polar: https://docs.osohq.com/reference/polar.html

I'd like to apply this to writing Kubernetes operators. They run along this line: https://www.usenix.org/legacy/publications/library/proceedin...

That is, trying to converge a system from current state to desired state.

If it were written with logic programming and were able to run things in reverse, then it would be able to explain exactly why it is unable to converge the system to the desired state, and what other factors it is waiting on to do so. I think that would greatly enhance observability in a complex system.

I was also in the process of writing a chat bot accepting commands be able to autocompletion that takes authorization into account. So given what the user has typed so far, and what it is authorized to use, it would be able to show the available commands.

As a proof of concept, I implemented a test scenario generator for work using Prolog. There was an existing tool and we stuck with it, but we essentially recreated a large bit of Prolog (a corollary to Greenspun's Tenth Rule) in doing so. The protocol being tested (a back and forth between, for my demo purposes, two nodes) was fairly easy to codify (if not byte-for-byte, structurally) in Prolog. So I could put in a message and have the program tell me what response was expected. Supply a few constraints for the scenario and you could generate a sequence of messages for both sides, one being what we'd transmit to the system under test, and the other the expected response back.

In principle, this would have allowed us to do something akin to property based integration testing (we only tested the fully integrated system, no partial integrations of subsystems or unit testing). The same program could have been used to analyze recordings of real world communications to see if they were correct (to the spec) and where they diverged if not, with only minor modification to the way we interacted with it.

That's actually one of the really nice things about Prolog, you can work in both directions with the same program, you can't do that in any of the mainstream programming languages without libraries (minikanren, for instance, allows for an embedding of this in many languages).

For instance, while trivial, you can use append/3 in Prolog to get the result of appending two lists, or to find all prefixes and suffixes of a list, or to find a particular prefix/suffix given both the combined list and the other (suffix or prefix, respectively).

  append([1,2], [3,4], AB).    -- AB = [1,2,3,4]
  append(A, [3,4], [1,2,3,4]). -- A = [1,2]
  append([1,2], B, [1,2,3,4]). -- B = [3,4]
  append(A, B, [1,2,3,4]).     -- A = [], B = [1,2,3,4];
                               -- A = [1], B = [2,3,4];
                               -- ...

By writing one program, perhaps supplying synonyms to get something that reads better, you can get all these options depending on which parts you choose to supply as knowns and which you leave as variables.

Board game rules. "Given the current state of the board, what are all the actions player 1 can do? Choosing one of those actions, which targets can they choose from?" etc.

There are techniques that are purely academic, but there are lots of cases where constraint modeling turns up and is useful. In my experience, the area where constraint programming is used the most is in applications that do things like scheduling and rostering.

Any kind of multi-component mechanical modeling will require the use of constraints. Single components in mechanical modeling literally use dimensional constraints.

UI Layout