Prolog Basics Explained with Pokémon(unplannedobsolescence.com) |
Prolog Basics Explained with Pokémon(unplannedobsolescence.com) |
I think this is explained in The Power of Prolog[1] that the answers coming from Prolog are not printing text to a terminal, they are valid Prolog terms(/data/code). That's why the result uses the same `;` for OR as code does. Answer (x ; y ; false) is "query can be answered by x or y or no other answer found". (This would let you do meta-programming, reasoning about the results and rewriting the results in a LISPy data-as-code way, if you were more advanced than I am).
Prolog systems do optimisations to jump to the correct answer without searching, if they can, (e.g. database style indexing on the facts and rules) and in those cases there is no code left to search after showing the first answer, no need to prompt the user "should I search for more answers in the remaining code?", and so no need for an output "false" to say "I finished searching and found no more solutions".
And because you don't control the engine (you're not supposed to think about it, after all), there's nothing you can do but rewrite the whole thing in a traditional programming language.
The same is true of SQL query planners. You can perform basic queries without understanding how your SQL engine of choice works under the hood, but if you want performance, you must understand how your DB works. SQL is just the interface.
This is different in kind from imperative programming languages (which are much closer in abstraction to the underlying machine architecture), but we rub along with SQL ok; why not Prolog?
However, most prolog books focus on rooting the declarative mindset because programmers are generally more familiar with imperative programming. But just as with SQL or lisp there are definitely good ways, bad ways and plain mistakes you can make when approaching a problem.
This is the definition of declarative programming[0].
One example I often think about is from Ken Silverman: "sub eax, 128" → "add eax, -128". So equivalent ways to write the same program may have different performance characteristics also depending on the tools that are applied. How many people could tell without trying which way to write this example is preferable?
The same phenomenon will be encountered in all kinds of languages, where engine and compiler improvements make existing code faster or slower.
In the Scryer Prolog discussions, Alex has shared a few ideas and considerations for possible improvements to the Prolog code, including the use of metaprogramming to automatically generate more general relations:
https://github.com/mthom/scryer-prolog/discussions/3221
I hope for an interesting followup article!
Another very interesting Prolog program by Alex is factgraph.pl:
https://github.com/alexpetros/factgraph.pl
It's a Prolog implementation of the IRS Fact Graph, an application of Law as Code.
What does this say about Forth? Not much except that it isn't for me.
Take Prolog. I know few things more insulting than having to code in
Prolog. Whereas Armstrong developed Erlang in Prolog and liked it much
better than reimplementing Erlang in C for speed. I can't imagine how
this could be, but this is how it was. People are different.
[0] https://yosefk.com/blog/my-history-with-forth-stack-machines...
https://github.com/mthom/scryer-prolog/discussions/3322
and also in the course of a discussion on various approaches to implement concurrency in Prolog:
Man, where was a post like this when I was struggling trying to learn Prolog, modelling something with knights and knaves...
Simple general-purpose opponents can be coded using just recursive backtracking search, while more advanced ones (supporting moves that need to destructively change state) can still be conveniently modelled by reifying facts and thereby enable backtracking over assert/retract-like Prolog DB modifications, as used in discrete combinatorial planners [1].
[1]: https://quantumprolog.sgml.net/container-planning-demo/part1...
SELECT DISTINCT pokemon, special_attack
FROM pokemon as p
WHERE
p.special_attack > 120
AND EXISTS (
SELECT 1
FROM pokemon_moves as pm
WHERE p.pokemon_name = pm.pokemon_name AND move = 'freezedry'
)
AND EXISTS (
SELECT 1
FROM pokemon_types as pt
WHERE p.pokemon_name = pt.pokemon_name AND type = 'ice'
);
SELECT DISTINCT pokemon, special_attack
FROM pokemon as p
NATURAL JOIN pokemon_moves as pm
NATURAL JOIN pokemon_types as pt
WHERE
p.special_attack > 120 AND
pm.move = 'freezedry' AND
pt.type = 'ice'
;
I think. Doing this in my head, but you could verify it trivially with SQLite or any other RDBMS.
Do you have an Odin tutorial that's as easy to digest?
Sol
https://www.broadlearners.com/t/understanding-the-meaning-of...
https://www.merriam-webster.com/grammar/whole-nother
https://old.reddit.com/r/etymology/comments/13s19j0/wtf_happ...
In my case, I was using it as almost a blend of the two meanings, something mostly meaning “unimpressed”, with a touch of “and a bit perplexed why such effort is going into this”. Basically a shoulder shrug and “okay…?”
I now find myself nonplussed, wondering if I should be using the word at all given it seems to have two opposite meanings.
In my opinion, a key difference between Prolog and other languages in that regard is one of degree, not kind: Compared to other languages, addressing performance problems in Prolog engines tends to have far greater effects on Prolog programs, because so much is implicit (i.e., left to the engine).
If the performance problem is not in the engine, but in the program itself, then we will face the same questions with Prolog as with other languages: How to formulate the program better, is there a better approach altogether?
For example, earlier today an interesting question regarding performance was posted in the Scryer discussions:
https://github.com/mthom/scryer-prolog/discussions/3341
The comparison in this case is between Gecode and Scryer on a seemingly simple but nontrivial combinatorial task. What is the problem here? Most likely the Scryer engine itself can be improved. And also very likely, there are better ways to model the task, and also better search strategies, and these tend to have far greater performance impact than the base language, and these questions remain also if we change the base language.
In my opinion, these questions regarding different kinds of formulations tend to be more frequently associated with Prolog than with other languages because Prolog is more frequently used for complex tasks where it is not a priori clear how to even approach the problem.
And yet Prolog can express all examples in the article. For these kinds of problems, giving up TC is mostly a feature. And if you need more expressiveness, there's a lot of practical Datalog-ish systems that can recover Turing completeness (Flix, Formulog, parts of Souffle), while still being saner than SWI Prolog and co. for this type of work, as you generally don't have to care about atom order or search order in the same way. They act so much more predictably.