Interfacing nondeterminism with the real world

[razetime]

I recently found an article from Vanessa McHale named Logic Programming Doesn't Work in the Real World, which tries to use Curry as an example for showing how nondeterminism does not lend itself well to working with I/O.

I found this conclusion odd:

Logic programming, however, is hopeless. It cannot deal with imperative constructs on its own terms, for deep reasons rooted in logic.

What would the ideal way for a logic programming language to work with the real world "on its own terms"? I only know of the impure methods and using DCGs with stream-oriented I/O, but I am not experienced enough to come up with a retort to this statement.

[emummel20]

Personally, I would love to see someone implement something cool based on Transaction Logic as an effects system.

[triska]

The specific quote appears in the context of "integrating with C":

Haskell remarkably succeeds in integrating with C, able to import C functions and work with them on its own terms. Logic programming, however, is hopeless. It cannot deal with imperative constructs on its own terms, for deep reasons rooted in logic.

We can very easily integrate Scryer Prolog with imperative languages such as C, using for example the foreign function interface library(ffi) by @aarroyoc, or the library facilities by @lucksus. Another common way to do this is via network connections, see library(sockets).

The terms "real world" appear in the post's title and in the following sentence:

Not only does nondeterminism recklessly duplicate the real world, constraints destroy the real world.

Personally, I think this sentence is false. Counterexample: I use a lot of nondeterminism and constraints in Prolog programs, and as far as I can tell, the real world is neither recklessly duplicated, nor destroyed.

library(pio) is a good example of an interaction between logic programming (including nondeterminism and constraints) and I/O: We can write our DCGs in pure logic, and then use a single predicate such as phrase_from_file/2 to apply the DCG to a file.

A corresponding phrase_to_file/2 is harder to implement efficiently. We currently provide only a very rudimentary (in the sense that it is very inefficient) version of it in library(pio), and there is an issue explaining properties of an efficient implementation: #691

Mercury uses additional arguments to represent the state of I/O: https://mercurylang.org/information/doc-latest/mercury_trans_guide/IO.html

[UWN]

Have you, @razetime, really tried Haskell's I/O? It is highly restrictive and "pollutes" programs. But, to be fair, it still permits a pure reading. What is so odd in the mentioned blog-post is that the required restrictions for pure functions are not seen as a disadvantage, but a restriction to determinism is seen as such a disadvantage. I think both are pretty much on the same level of annoyance.

A similar I/O system for Prolog is thinkable, in fact Mercury has it. However, I guess that it would not be too popular. Haskell and Mercury can delegate most of the restrictions into the type system leaving a programmer only with the option to love it or leave. In Prolog the corresponding errors would only occur at runtime and thus people could be tempted to "work around it".

Sometimes differences only show in the very fine print. Think of library(pio). There, one can argue, support for non-determinism is in fact the reason why some programs use constant memory, whereas the straight-forward Haskell solutions require space proportional to the file read. (Currently this still needs GC in Scryer, but you will see it also here). See this paper.