Rethinking Prolog (opens in new tab)

I tried Turbo Prolog[1] back in the 1980s. I could never figure out how to get it to do file I/O at that time, so I got frustrated and gave up. Even now, it looks fairly hopeless as a language.

Is there a modern example of the language that can do file I/O? To me, if you can't do I/O, there's no point to a language. It's why Standard Pascal lost so much ground to Turbo Pascal with it's excellent I/O support.

[1] https://ia802902.us.archive.org/1/items/bitsavers_borlandtur...

I wish I had never opened this thread... I hate Prolog with a burning passion now, I just thought it was weird earlier. It makes brainfuck look like a walk in the park.

  ?- write(10-2).
  10-2
  true.

Why do I care? I figured out how to count to 5

  ?- foreach(between(0,5,N),writeln(N)).
  0
  1
  2
  3
  4
  5
  true.

Then since there's no way to count down, I figured I'd just do a bit of math

  ?- foreach(between(0,5,N),writeln(5-N)).
  5-0
  5-1
  5-2
  5-3
  5-4
  5-5
  true.

I can not find a single way to force the evaluation before printing, it's nuts!

A better link: https://okmij.org/ftp/kakuritu/rethinking.pdf

The OCaml library mentioned in the paper appears to be linked as individual files from the web page here: https://okmij.org/ftp/kakuritu/Hansei.html

...not sure if it's properly published as a package anywhere.

Looks like someone collected it to GitHub here: https://github.com/cararemixed/hansei

There's some discussion here that the Hansei code may no longer work under OCaml 5: https://discuss.ocaml.org/t/multi-shot-continuations-gone-fo...

Could someone ELI5 for me how this stuff relates to Kanren? It looked superficially similar.

Past thread: https://news.ycombinator.com/item?id=8305486

Meh. As usual, functional programmers look at Prolog and completely miss the point. "Classical Prolog" (which part?) is "all about nondeterminism"?

The nondeterminism in Prolog comes from the completeness of SLD-Resolution as an inference rule. Because SLD-Resolution is complete [1], it can find every proof that exists. When there are many proofs, it is natural to have some mechanism to represent them all. Prolog does that by backtracking and trying different branches of a proof, hierarchically.

Parsing is indeed a good example of this. When a grammar is ambiguous, a string may have multiple different parses. But if a grammar is ambiguous, that's because the language it represents is ambiguous, and that means we want to represent the ambiguity, and have multiple parses. That is where a mechanism for nondeterministic return of all results is needed. A parser written in Prolog [2] will naturally backtrack and get all parses of a string.

So how about that maudlin cut, that people, like the authors of the article above, have bitched and moaned about, since the creation of Prolog? Well the cut clearly exists to avoid reaching unwanted branches of a proof, or in other words, to avoid unwanted backtracking.

But why then is there unwanted backtracking? The reason for unwanted backtracking is, invariably, that a program is over-general. In over-generalising, the program non-deterministically generates results that the programmer did not want, even as it returns (hopefully first) the results that the programmer wants. But human programmers are not perfect, and sometimes it can be too hard to write a program that is exactly as general, and as specific, as one wants, especially when the program crosses some threshold of size beyond which it is difficult to keep all of one's ducks in a row and understand exactly the behaviour of every single sub-program (i.e. predicate definition). That is when the cut is needed. The cut is a time-saver that keeps you from having to rewrite your entire program from scratch, multiple times, just because you are an imperfect programmer, and you cannot handle the full might of a programming language with Universal Turing Machine expressivity.

And more esoterically, perhaps, unwanted non-determinism arises because Resolution is semi-decidable, meaning that if a proof exists, Resultion will find it, but if a proof does not exist, it will keep trying forever. And that is the best that can be achieved under the Church-Turing thesis, and if you are unhappy with that, you can take your case with Mr. Gödel. In the meantime, you can use the cut to avoid your program going haywire, when you can tell (but the Prolog interpreter can't, because Church-Turing) that a program will loop forever after succeeding n times.

The authors say that "Classical Prolog" (really, what is that?) is not a "general purpose programming language". It is. Thanks to the cut. Now shoo, go code in your functional languages, which are safe and easy. Don't mess with my Prolog because you don't understand it.

___________________

[1] More precisely, SLD-Resolution is both sound and refutation complete.

[2] Generally, as a Definite Clause Grammar.

[3] https://www.doc.ic.ac.uk/~rak/papers/IFIP%2074.pdf

I did some Prolog programming in school but I never really got the language coming from a Pascal/C background. Your first language(s) really do affect your future learning.

Too long did not read. Me thinks Prolog should be parallel only now that we have AI-machines and such shit. It should starts every direction immediately and when some criteria is fulfilled it should start dropping answers without ever reaching the end.

fib(X,Y1+Y2):- fib(X-1,Y1),fib(X-2,Y2).

This should be legal kwestion and machine should start spewing numbers from zero to infinity.