I can recall the problems with "cut" and "not" being discussed in the 1980s ... there are now a number of solutions:
- if-then-else (note that *-> does backtrack over the condition)
- Picat/Haskell style single-sided-unification
- freeze/2 for delaying the computation of a "not" until the arguments are sufficiently instantiated
- attributed variables (a generalization of freeze/2)
Yes, setof/3, bagof/3, find all/3 are confusing (see also library(aggregate)). These have to do with the implicit "for all" qualification which requires being explicit about "there exists" -- one solution is to write auxiliary predicates rather than trying to be clever for complex goals ... this also gets into problems with free variables, which have never been satisfactorily resolved (e.g., library(yall) allows something like lambda expressions; but can lead to surprises similar to the "exists" surprise in set of/3).
AST is a nicer approach than setof/3 and friends; but it also comes at a computational cost. Similarly, Constraint Logic Programming (https://www.swi-prolog.org/pldoc/man?section=clp) generalizes the handling of "not", but also at a computational cost.
Picat takes a different approach (e.g., it doesn't allow treating code as data) and has some much more powerful features -- it's great for solving "Advent of Code" problems -- but if you read its forum, you'll see subtle difficulties with using its various solvers.
None of these solution are fully satisfying, but many are related to how to handle the undecidability parts of first-order logic, and how to handle competing design goals (e.g., better handling of variable scope would cause problems with manipulating programs as data)
(I could a long list of other issues in Prolog: scope of names, macros, modules, foreign-language interfaces, compatibility with (relational) databases, etc., etc.)
Such conundrums aren't unique to Prolog -- look at all the variants of Lisp where what seem like minor changes to semantics in edge cases result in new languages (e.g., Scheme).
I suspect that one sign of a language being useful is that some of its features are controversial.
I can recall the problems with "cut" and "not" being discussed in the 1980s ... there are now a number of solutions: - if-then-else (note that *-> does backtrack over the condition) - Picat/Haskell style single-sided-unification - freeze/2 for delaying the computation of a "not" until the arguments are sufficiently instantiated - attributed variables (a generalization of freeze/2)
Yes, setof/3, bagof/3, find all/3 are confusing (see also library(aggregate)). These have to do with the implicit "for all" qualification which requires being explicit about "there exists" -- one solution is to write auxiliary predicates rather than trying to be clever for complex goals ... this also gets into problems with free variables, which have never been satisfactorily resolved (e.g., library(yall) allows something like lambda expressions; but can lead to surprises similar to the "exists" surprise in set of/3).
AST is a nicer approach than setof/3 and friends; but it also comes at a computational cost. Similarly, Constraint Logic Programming (https://www.swi-prolog.org/pldoc/man?section=clp) generalizes the handling of "not", but also at a computational cost.
Picat takes a different approach (e.g., it doesn't allow treating code as data) and has some much more powerful features -- it's great for solving "Advent of Code" problems -- but if you read its forum, you'll see subtle difficulties with using its various solvers.
None of these solution are fully satisfying, but many are related to how to handle the undecidability parts of first-order logic, and how to handle competing design goals (e.g., better handling of variable scope would cause problems with manipulating programs as data)
(I could a long list of other issues in Prolog: scope of names, macros, modules, foreign-language interfaces, compatibility with (relational) databases, etc., etc.)
Such conundrums aren't unique to Prolog -- look at all the variants of Lisp where what seem like minor changes to semantics in edge cases result in new languages (e.g., Scheme).
I suspect that one sign of a language being useful is that some of its features are controversial.