Yes, you could do this and it's likely it'll turn out as rather nice and decently performant code. You would, however, most likely run into the problem of findi

Yes, you could do this and it's likely it'll turn out as rather nice and decently performant code. You would, however, most likely run into the problem of finding people to maintain it that are willing to learn. Most Prolog teaching material is quite abstract in the sense that it mainly teaches the language and its tricks, not so much applications, though there are of course a lot of FOSS and example applications to look at. In practice you would have to write documentation that basically turns into a course on constraint solving in Prolog. There are footguns and somewhat advanced techniques involving control over the execution strategy that are going to trip up newcomers. You'll also have to figure out how to interface with a Prolog implementation. A compromise might be to use bindings for Z3 or something like the Timefold solver, https://timefold.ai/open-source-solver https://timefold.ai/open-source-solver. Either way it's a good idea to spend some time playing around with Scryer, https://www.scryer.pl/ https://www.scryer.pl/, and Markus Triska's crash course, https://www.metalevel.at/prolog https://www.metalevel.at/prolog. SWI-Prolog has more conveniences that might make it more suitable for practical applications, but being used to them might make it harder to adapt to e.g. Scryer, Tau or some other implementation. There's also the Mercury language, it's weirder but also very interesting, https://mercurylang.org/ https://mercurylang.org/. Edit: Some people swear by Picat but I have very little experience with it, http://picat-lang.org/ http://picat-lang.org/.