Prolog and side-effects are a really unfortunate pairing. What I would love is when backtracking over a side-effect, that effect would be taken back. With transactions that might even be possible. As it stands, quering (pseudocode) "connect(C), insert(C, data), false" has no solution but side-effects. SLD-resolution probably just does not work with side-effects.
In some sense, whenever there's a choice (or a checkpoint) between two branches, each branch should morally get its own copy of the world; and effects should only leak out when both branches incur the same observable effect. (This is motivated by the logical law `(A v B) ^ (A -> C) ^ (B -> C) -> C`.) Of course, that's hard to do when interacting with external systems!
PostgreSQL-Prolog: A Prolog library to connect to PostgreSQL databases
21–23 of 23 posts
Re: PostgreSQL-Prolog: A Prolog library to connect to PostgreSQL databases
#22Earlier quoted context omitted.
In some sense, whenever there's a choice (or a checkpoint) between two branches, each branch should morally get its own copy of the world; and effects should only leak out when both branches incur the same observable effect. (This is motivated by the logical law `(A v B) ^ (A -> C) ^ (B -> C) -> C`.) Of course, that's hard to do when interacting with external systems!
Do you know of any work on this? I have a prototype implementation for a side-effects prolog library with a similar semantics and I'm working on the corresponding paper.
I do think consensus algorithms have something deeply in common here, as CALM (Consistency As Logical Monotonicity) seems to cover the space of join-semilattice structures pretty crisply, and CALM is all about when you don't need consensus. But again, just my own musings.