5 ms·

>All the high-level abstraction also makes it much harder to read All that abstraction can also make code easier to read by hiding details irrelevant to a func

by knome 4y ago

>All the high-level abstraction also makes it much harder to read All that abstraction can also make code easier to read by hiding details irrelevant to a function. Not that you can't do similar abstractions in prolog. When I wrote my bf-in-prolog implementation [1] to play with the language, I found myself writing functions to create a purposed wad of data and then manipulate or extract from it, so the rest of the program could neatly ignore how that wad of data actually worked internally, in much the same way as I would in any language. >why Prolog is hard to learn Prolog is a pretty standard functional programming language, just hidden in a backtracking query runner. All of the introductions and tutorials generally start from the query runner's point of view, of facts and rules and backtracking with examples of `parent(This,That)` and showing it can identify grandparents or cousins or whatever, so it's little wonder that most programmers aren't going to bother sifting through to see it's just a little pattern-matching haskell/c++-template-language kind of thing. >you don't even declare variables, as such, in Prolog, there's no assignment expressions I definitely viewed unification as a form of variable assignment ( understanding it would backtrack if unable to assign ). There is a `=` in there to unify a variable with another variable or a given chunk of data. I used it to initialize data structures and to terminate recursive calls by assigning to the 'out' variable. I understand it's "unifying" rather than "assigning", but the effect is the same if you know one of the variables to be unbound. Otherwise it's just an assertion of equality (unifiability?) between the two values. ----- [1] https://github.com/knome/bf-in-prolog https://github.com/knome/bf-in-prolog

dreamcompiler 4y ago
> Prolog is a pretty standard functional programming language, just hidden in a backtracking query runner. Disagree. The fundamental difference (to me) is that in a functional language you write functions that have inputs and outputs. You can write code like this in Prolog, but Prolog encourages the idea that there's no such thing as an input or an output; there are only relations. If you write a function such as c = a + b in a functional language you cannot just say "here are c and a; tell me what b is." That idea makes no sense in a functional language, but Prolog will simply tell you what b is. You can even say "here is c; give me an assortment of a's and b's that make the relation true" and Prolog will start listing them off (albeit probably not very efficiently, and one does not typically use this capability for simple arithmetic). This is a very different way of thinking about functions because they are inherently "bidirectional" and it's one of the things that makes Prolog feel more like a magical query language than a functional language.
- knome 4y ago
  This works for simple little functions, but if someone was going to use prolog for anything complex, it would quickly be impossible. There aren't going to be functions that take a rendered page and an alist of values and return the template. Or that reverse hashing. Or really anything very complex. For using prolog in its original purpose as a database of queryable facts and rules, this is useful, but as a general purpose programming language, I think it's more of a parlor trick.
  - dreamcompiler 4y ago
    I don't think it's really about "simple" functions per se. Bidirectionality is useful where function inversion is meaningful (i.e. not for hashing) and where the domain of the function is explicitly finite or otherwise bounded by constraints. That's exactly the situation when querying databases. Such queries can get quite complicated. Agreed that it's not that useful for GP programming, but it's very useful for databases and constraint management systems.
YeGoblynQueenne 4y ago
>> Prolog is a pretty standard functional programming language, just hidden in a backtracking query runner. I'm perplexed by your comment. Prolog is not a functional language. It's a logic programming language. The terminology about "queries" and "facts" and "rules" is extremely unfortunate. I think it's inherited from databases, because of the common implementation trick of storing Prolog programs in a relational database. But explaining Prolog in these terms, as is indeed very common, only begets endless confusion. For instance, there is no "query runner" in Prolog. Because there are no "queries". What people call a Prolog "query" is really a Horn goal proved by SLD-refutation with respect to a set of defintie clauses, i.e. a Prolog program. The point of all that is automated proofs. It just so happens that proving first-order logic theories and executing programs is the same, hence we can write a logic program as a theory and run a proof to execute it. >> I definitely viewed unification as a form of variable assignment ( understanding it would backtrack if unable to assign ). Yes, that's a common mistake to make, and not your fault. These things are never explained in Prolog courses. You can think of unification as a form of equality, as you say, but in truth, unification is a clever optimisation that makes execution efficient. It makes it possible to run an SLD-refutation proof without having to ground the entire program into a set of propositions, first. But to understand what the hell that means you really need to understand resolution theorem-proving, and a lot of theory about first-order logic, that is simply not taught to programmers. I was very confused about all that myself, right up until the first year of my PhD when I finally had the leisure (and the need) to sit down and really try to get to grips with the material. But I don't think one needs a PhD to understand all that. What is really needed is better teaching that doesn't muddle the water with useless terminology about "queries" and "facts" and "rules" and so on.
- knome 4y ago
  >I'm perplexed by your comment. Prolog is not a functional language. It's a logic programming language. It's my impression from its use of recursion for execution flow alongside its assign-once variables, which feel a lot like haskell's lazy evaluation.
  - knome 4y ago
    Wanting to see what you saw wrong with my impression of prolog, I spent some time digging into the language. It does have an "if then else"-like statement via (->) and (;) `repeat/0` is incredibly gross looking. The examples use it like 'yield' to unify a name and let the rest of the clauses run. It appears to it creates infinite choice-points that must eventually be manually escaped from with a cut (!)? https://www.swi-prolog.org/pldoc/doc_for?object=repeat/0 https://www.swi-prolog.org/pldoc/doc_for?object=repeat/0

by knome 4y ago

dreamcompiler 4y ago

> Prolog is a pretty standard functional programming language, just hidden in a backtracking query runner. Disagree. The fundamental difference (to me) is that in a functional language you write functions that have inputs and outputs. You can write code like this in Prolog, but Prolog encourages the idea that there's no such thing as an input or an output; there are only relations. If you write a function such as c = a + b in a functional language you cannot just say "here are c and a; tell me what b is." That idea makes no sense in a functional language, but Prolog will simply tell you what b is. You can even say "here is c; give me an assortment of a's and b's that make the relation true" and Prolog will start listing them off (albeit probably not very efficiently, and one does not typically use this capability for simple arithmetic). This is a very different way of thinking about functions because they are inherently "bidirectional" and it's one of the things that makes Prolog feel more like a magical query language than a functional language.

knome 4y ago
This works for simple little functions, but if someone was going to use prolog for anything complex, it would quickly be impossible. There aren't going to be functions that take a rendered page and an alist of values and return the template. Or that reverse hashing. Or really anything very complex. For using prolog in its original purpose as a database of queryable facts and rules, this is useful, but as a general purpose programming language, I think it's more of a parlor trick.
- dreamcompiler 4y ago
  I don't think it's really about "simple" functions per se. Bidirectionality is useful where function inversion is meaningful (i.e. not for hashing) and where the domain of the function is explicitly finite or otherwise bounded by constraints. That's exactly the situation when querying databases. Such queries can get quite complicated. Agreed that it's not that useful for GP programming, but it's very useful for databases and constraint management systems.

YeGoblynQueenne 4y ago

>> Prolog is a pretty standard functional programming language, just hidden in a backtracking query runner. I'm perplexed by your comment. Prolog is not a functional language. It's a logic programming language. The terminology about "queries" and "facts" and "rules" is extremely unfortunate. I think it's inherited from databases, because of the common implementation trick of storing Prolog programs in a relational database. But explaining Prolog in these terms, as is indeed very common, only begets endless confusion. For instance, there is no "query runner" in Prolog. Because there are no "queries". What people call a Prolog "query" is really a Horn goal proved by SLD-refutation with respect to a set of defintie clauses, i.e. a Prolog program. The point of all that is automated proofs. It just so happens that proving first-order logic theories and executing programs is the same, hence we can write a logic program as a theory and run a proof to execute it. >> I definitely viewed unification as a form of variable assignment ( understanding it would backtrack if unable to assign ). Yes, that's a common mistake to make, and not your fault. These things are never explained in Prolog courses. You can think of unification as a form of equality, as you say, but in truth, unification is a clever optimisation that makes execution efficient. It makes it possible to run an SLD-refutation proof without having to ground the entire program into a set of propositions, first. But to understand what the hell that means you really need to understand resolution theorem-proving, and a lot of theory about first-order logic, that is simply not taught to programmers. I was very confused about all that myself, right up until the first year of my PhD when I finally had the leisure (and the need) to sit down and really try to get to grips with the material. But I don't think one needs a PhD to understand all that. What is really needed is better teaching that doesn't muddle the water with useless terminology about "queries" and "facts" and "rules" and so on.

knome 4y ago
>I'm perplexed by your comment. Prolog is not a functional language. It's a logic programming language. It's my impression from its use of recursion for execution flow alongside its assign-once variables, which feel a lot like haskell's lazy evaluation.
- knome 4y ago
  Wanting to see what you saw wrong with my impression of prolog, I spent some time digging into the language. It does have an "if then else"-like statement via (->) and (;) `repeat/0` is incredibly gross looking. The examples use it like 'yield' to unify a name and let the rest of the clauses run. It appears to it creates infinite choice-points that must eventually be manually escaped from with a cut (!)? https://www.swi-prolog.org/pldoc/doc_for?object=repeat/0 https://www.swi-prolog.org/pldoc/doc_for?object=repeat/0