the-power-of-prolog VS chalk

Prolog is excellent for bikeshedding, in fact that might be its strongest axis. It starts with everything you get in a normal language such as naming things, indentation, functional purity vs side effects, where to break code into different files and builds on that with having your names try to make sense in declarative, relational, logical and imperative contexts, having your predicates (functions) usable in all modes - and then performant in all modes - having your code be deterministic, and then deterministic in all modes. Being 50 years old there are five decades of learning "idiomatic Prolog" ideas to choose from, and five decades of footguns pointing at your two feet; it has tabling, label(l)ing, SLD and SLG resolution to choose from. Built in constraint solvers are excellent at tempting you into thinking your problem will be well solved by the constraint solvers (it won't be, you idiot, why did you think that was a constraint problem?), two different kinds of arithmetic - one which works but is bad and one which mostly works on integers but clashes with the Prolog solver - and enough metaprogramming that you can build castles in the sky which are very hard to debug instead of real castles. But wait, there's more! Declarative context grammars let you add the fun of left-recursive parsing problems to all your tasks, while attributed variables allow the Prolog engine to break your code behind the scenes in new and interesting ways, plenty of special syntax not to be sneezed at (-->; [_|[]] {}\[]>>() \X^+() =.. #<==> atchoo (bless you)), a delightful deep-rooted schism between text as linked lists of character codes or text as linked lists of character atoms, and always the ISO-Standard-Sword of Damocles hanging over your head as you look at the vast array of slightly-incompatible implementations with no widely accepted CPython-like-dominant-default.

Somewhere hiding in there is a language with enough flexibility and metaprogramming to let your meat brain stretch as far as you want, enough cyborg attachments to augment you beyond plain human, enough spells and rituals to conjour tentacled seamonsters with excellent logic ability from the cold Atlantic deeps to intimidate your problem into submission.

Which you, dear programmer, can learn to wield up to the advanced level of a toddler in a machine shop in a mere couple of handfuls of long years! Expertise may take a few lifetimes longer - in the meantime have you noticed your code isn't pure, doesn't work in all modes, isn't performant in several modes, isn't using the preferred idiom style, is non-deterministic, can't be used to generate as well as test, falls into a left-recursive endless search after the first result, isn't compatible with other Prolog Systems, and your predicates are poorly named and you use the builtin database which is temptingly convenient but absolutely verboten? Plenty for you to be getting on with, back to the drawing boar...bikeshed with you.

And, cut! No, don't cut; OK, green cuts but not red cuts and I hope you aren't colourblind. Next up, coroutines, freeze, PEngines, and the second 90%.

Visit https://www.metalevel.at/prolog and marvel as a master deftly disecting problems, in the same way you marvel at Peter Norvig's Pytudes https://github.com/norvig/pytudes , and sob as the wonders turn to clay in your ordinary hands. Luckily it has a squeaky little brute force searcher, dutifully headbutting every wall as it explores all the corners of your problem on its eventual way to an answer, which you can always rely on. And with that it's almost like any other high level mostly-interpreted dynamic programming / scripting language.

There is also AI that isn't machine learning. One could use formal logic to state rules and facts about the world and infer things from that. This sounds attractive but the main issue is that you need to build and maintain all of this knowledge. Most oldschool AI falls into this category. There's also fun programming languages like Prolog that are deep into this school: https://www.metalevel.at/prolog

There's a nice book[1][2] about Prolog, with modern characteristics. Moreover, there are things like ProbLog[3] and DeepProbLog[4] that allow you to use probabilistic reasoning and power of machine learning. I am personally looking forward for Scryer Prolog[5] to achieve its goals.

[1] https://www.metalevel.at/prolog

[2] https://github.com/triska/the-power-of-prolog

[3] https://github.com/ML-KULeuven/problog

[4] https://github.com/ML-KULeuven/deepproblog

[5] https://github.com/mthom/scryer-prolog

I had the same troubles until I encountered Markus Triska's modern perspective on revitalizing Prolog: https://www.metalevel.at/prolog.

The Power of Prolog [0] is a fantastic blog/video series covering everything from basic syntax, theoretical basis, modern features and idiomatic constructs.

I highly recommend it if you want to get the gist of Prolog and its modern features.

If you want a tour of Prolog, you can watch the video with that name [1].

[0]: https://www.metalevel.at/prolog

[1]: https://youtu.be/8XUutFBbUrg

I've gone through The Art of Prolog, most of The Power of Prolog, and a good chunk of the P-99 problems, and I have to say I'm simultaneously fascinated by and sceptical of Prolog. For some problem domains, implicit search is a very desirable property, and I can definitely see Prolog shining in that case. There are also many desirable properties and possibilities that are often reiterated, but concrete examples of how they would work are often missing. It comes down to: how does "production Prolog" look? A talk on Strange Loop by Michael Hendricks on exactly that topic was really helpful (especially w.r.t. some useful tools and libraries: func and yall are really great, and I still need to check mavis), but it still leaves me wondering on a couple of things.

Pretty much every Prolog book is quite good, but if you have the money or a local library with a copy, I really like Programming in Prolog by Clocksin, or Art of Prolog by Stering and Shapiro. If you want to follow a web resource, the standard suggestion is Markus Triska's The Power of Prolog.

The Rust compiler uses a Prolog-like query language internally for type checking generic requirements and traits: https://github.com/rust-lang/chalk

rust-analyzer already uses chalk (https://github.com/rust-lang/chalk) which should replace the current trait resolver.

Well it's quite easy to come to that conclusion: The code compiles with rustc, which is currently the reference implementation. If rust-analyzer does not match rustc's behavior it's an issue in their implementation. That written it's not that easy to fix as it's related to how rust-analyzer resolves types/traits. rust-analyzer uses chalk for this, which is known to be incomplete/diverging from the RFC'ed behavior. Now one could argue that we can simplify diesel to the point where it works will with rust-analyzer/chalk, but that would result in basically removing core diesel features that exist way longer than rust-analyzer.

> Not all of those things work well in the real world. E.g. logic programming (prolog) is cool but ultimately never really caught on.

It does have its niches though. For example, there is a trait solver for Rust called Chalk that uses a Prolog-inspired language because trait bounds basically define a logic:

https://github.com/rust-lang/chalk

Maybe something in the prolog/datalog direction could be useful? Notably Rust has Chalk to help with trait resolution ("Chalk is a library that implements the Rust trait system, based on Prolog-ish logic rules.")

There has been work to implement part of the Rust typing logic in the Chalk Engine which uses a prolog-ish syntax to describe its rules.

That's something Chalk is trying to tackle.

We probably will see all of them at some point -- polonius is a current effort to make the borrow checker accept more valid programs, in a way that also simplifies the logic and is probably a bit faster than the current NLL system, chalk is an attempt to do a similar thing for the trait system, and cranelift is a project that seeks to replace the LLVM codegen backend. But obviously, these are very large and complex projects that are gonna take some time.

Do Rust developers realize that? Oh, yes, absolutely, that's why we have this:

For me an attempt to write where HashMap: FromIterator and then use new and insert was totally bizzare because currently rustc is pretty primitive and doesn't do super-complex machinery needed to do what you want. Chalk may fix that one day, but it's nowhere near to being ready for inclusion into rustc thus I wouldn't even attempt to do what you tried to do… but that's not something you are supposed to know before reading this book!