3 ms·

While turing complete, it is essentially a DSL for doing logical deductions in a system of predicate logic. This makes it quite natural for certain classes of

While turing complete, it is essentially a DSL for doing logical deductions in a system of predicate logic. This makes it quite natural for certain classes of search and constraint satisfaction problems, but less natural for day-to-day procedural programming. Further more, it is missing many things that you come to expect in a modern programming language - arrays, good numerical performance, etc. The way it works though allows you to do some things quite beautifully. For example, since every function you right can be run either forwards or backwards (solving for any one unknown amongst the arguments or result), you can often write one single piece of logic for parsing that can just be run in reverse to do serialization (or vice versa). The main reason, though, that it (or it's progeny like Mercury) is not mainstream is really the same as the reason that Haskell and its derivatives are not. It's just too different from the more widely known algol/simula langages, and the library ecosystem is comparatively poor.

YeGoblynQueenne 6y ago
>> Further more, it is missing many things that you come to expect in a modern programming language - arrays, good numerical performance, etc. Those depend on the interpreter. For example, Gnu Prolog has full support for arrays. Swi-Prolog has good support for rational numbers. Constraint libraries like library(clpfd) in Swi-Prolog simplify numerical computations. etc. About numerical support in particular, the problem is that representing arithmetic in first order logic is not straightforward because it doesn't have a concept of a "number"- so what a "number" is, must be defined before arithmetic can be done (and in fact, to some extent, this was the purpose of FOL in the first place). Additionally, Prolog slightly departs from first order logic semantics in that it doesn't have a clearly defined concept of "function" (by contrast in FOL "arguments" of predicates are variables, constants or functions). Instead, Prolog "cheats" and allows predicates to be passed as arguments to predicates. However, for performing arithmetic operations, Prolog defines a predicate is/2 that takes as arguments two "mathematical expressions", where an expression is either a number ...or a function (so a function; because constants are functions with 0 arguments). For example, to add two numbers you would write: ?- A is 1 + 1. A = 2. This is clunky and messy and ends up hurting the eyes and the brain, even though there's no real problem with performance in particular (in most Prolog systems there's a low-level back-end that handles that anyway). The constraint library clpfd that I mention above exists to smooth out this impedance mismatch between the declarative paradigm and the wonky "functions in a language without functions" of mainline Prolog. It's billed as "declarative integer arithmetic" (and does the job well) (once you get used to it). Anyway it's not that there's no good support for numerical computations. It's just ...weird. Even in the context of, you know, Prolog.

YeGoblynQueenne 6y ago

>> Further more, it is missing many things that you come to expect in a modern programming language - arrays, good numerical performance, etc. Those depend on the interpreter. For example, Gnu Prolog has full support for arrays. Swi-Prolog has good support for rational numbers. Constraint libraries like library(clpfd) in Swi-Prolog simplify numerical computations. etc. About numerical support in particular, the problem is that representing arithmetic in first order logic is not straightforward because it doesn't have a concept of a "number"- so what a "number" is, must be defined before arithmetic can be done (and in fact, to some extent, this was the purpose of FOL in the first place). Additionally, Prolog slightly departs from first order logic semantics in that it doesn't have a clearly defined concept of "function" (by contrast in FOL "arguments" of predicates are variables, constants or functions). Instead, Prolog "cheats" and allows predicates to be passed as arguments to predicates. However, for performing arithmetic operations, Prolog defines a predicate is/2 that takes as arguments two "mathematical expressions", where an expression is either a number ...or a function (so a function; because constants are functions with 0 arguments). For example, to add two numbers you would write: ?- A is 1 + 1. A = 2. This is clunky and messy and ends up hurting the eyes and the brain, even though there's no real problem with performance in particular (in most Prolog systems there's a low-level back-end that handles that anyway). The constraint library clpfd that I mention above exists to smooth out this impedance mismatch between the declarative paradigm and the wonky "functions in a language without functions" of mainline Prolog. It's billed as "declarative integer arithmetic" (and does the job well) (once you get used to it). Anyway it's not that there's no good support for numerical computations. It's just ...weird. Even in the context of, you know, Prolog.