5 ms·

I learned the basics of Prolog, really liked the idea, but found it rather impractical for complex problems. IMO, there needs to be a stronger separation betwee

I learned the basics of Prolog, really liked the idea, but found it rather impractical for complex problems. IMO, there needs to be a stronger separation between rule descriptions and search algorithm description/manipulation. I want to be able to specify an infinitely recursive rule, but avoid falling down the rabbit hole while running queries. Cuts could also be moved into this "search algorithm description".

ggggtez 8y ago
>infinite recursion >finite runtime I think there is a bug in between the keyword and the chair.
- KirinDave 8y ago
  Functional programmers work with infinitely recursive structures and data all the time and it doesn't really bother them, so this isn't automatically an absurd thing to say. Just because structures, rules and trees are infinitely recursive doesn't mean no insight can be created from them in finite time.
- cgrand-net 8y ago
  Not necessarily. One can use tabling (memoization) to prevent that. Also sometimes reordering clauses in the body of a rule is enough to avoid infinite runtime. Datalog (or SQL + recursive CTE) don't have this problem. Mozart/Oz or Alice allow to specify the search strategy.
- GavinMcG 8y ago
  Other people are explaining why you're wrong, but I'd like to point out that even if you were right, your comment would still be nearly worthless. Merely pointing out that someone else isn't correct might even have negative net value. For one thing, it can be construed as simple disagreement, opening up a debate that shouldn't happen when there really is a definitive answer. For another, it's insulting (especially as you did it) and that's not a necessary part of correcting someone's understanding. Invest a few more minutes next time to actually make a substantive comment. You'll be helping the person you correct, you'll be helping whoever else reads the thread, and you'll ultimately be helping yourself – by opening up your views to an actual constructive process.
tr352 8y ago
Answer set programming [1] may be what you're looking for. [1] https://en.wikipedia.org/wiki/Answer_set_programming https://en.wikipedia.org/wiki/Answer_set_programming
segmondy 8y ago
You learned the basics. You need to really understand the language to gain from it. Learning the basic is like writing non pythonic code or trying to write Lisp as if it's C. You are going to end up with major frustrations. It's like driving a truck and then learning to try a sports car cautiously like an overloaded truck, you won't enjoy it! Lispers love to talk about "code is data" In prolog, "data is code" and until you grok that, it's really difficult to experience the Prolog enlightenment.
tom_mellior 8y ago
One approach to taking existing Prolog code and executing it with different semantics (like a different search algorithm, but also tracing, debugging, etc.) is through metainterpreters. These are Prolog programs that interpret Prolog programs; you can write one in a few dozen lines. You can find several examples at https://www.metalevel.at/acomip/ https://www.metalevel.at/acomip/, including one in the "Changing the search strategy" section that does what you want. The drawback of metainterpretation is that it is, well, an interpreter layered on top of (on many systems) another interpreter. If you need your Prolog code to be really really "fast", then this approach may be "too slow". (Quotes because people love complaining about the speed of computation even in many situations where it really does not matter.) A different approach is to use code generation. Prolog programs are collections of Prolog terms; once you have written the abstract computation you want, you can write a program that takes that code, mangles it into a different form, then compiles that new form just as if you had written it by hand. So in summary, the separation you ask for is not there, but you have much more powerful tools than most other languages to implement it yourself quite easily.

ggggtez 8y ago

>infinite recursion >finite runtime I think there is a bug in between the keyword and the chair.

KirinDave 8y ago
Functional programmers work with infinitely recursive structures and data all the time and it doesn't really bother them, so this isn't automatically an absurd thing to say. Just because structures, rules and trees are infinitely recursive doesn't mean no insight can be created from them in finite time.
cgrand-net 8y ago
Not necessarily. One can use tabling (memoization) to prevent that. Also sometimes reordering clauses in the body of a rule is enough to avoid infinite runtime. Datalog (or SQL + recursive CTE) don't have this problem. Mozart/Oz or Alice allow to specify the search strategy.
GavinMcG 8y ago
Other people are explaining why you're wrong, but I'd like to point out that even if you were right, your comment would still be nearly worthless. Merely pointing out that someone else isn't correct might even have negative net value. For one thing, it can be construed as simple disagreement, opening up a debate that shouldn't happen when there really is a definitive answer. For another, it's insulting (especially as you did it) and that's not a necessary part of correcting someone's understanding. Invest a few more minutes next time to actually make a substantive comment. You'll be helping the person you correct, you'll be helping whoever else reads the thread, and you'll ultimately be helping yourself – by opening up your views to an actual constructive process.

tr352 8y ago

Answer set programming [1] may be what you're looking for. [1] https://en.wikipedia.org/wiki/Answer_set_programming https://en.wikipedia.org/wiki/Answer_set_programming

segmondy 8y ago

You learned the basics. You need to really understand the language to gain from it. Learning the basic is like writing non pythonic code or trying to write Lisp as if it's C. You are going to end up with major frustrations. It's like driving a truck and then learning to try a sports car cautiously like an overloaded truck, you won't enjoy it! Lispers love to talk about "code is data" In prolog, "data is code" and until you grok that, it's really difficult to experience the Prolog enlightenment.

tom_mellior 8y ago

One approach to taking existing Prolog code and executing it with different semantics (like a different search algorithm, but also tracing, debugging, etc.) is through metainterpreters. These are Prolog programs that interpret Prolog programs; you can write one in a few dozen lines. You can find several examples at https://www.metalevel.at/acomip/ https://www.metalevel.at/acomip/, including one in the "Changing the search strategy" section that does what you want. The drawback of metainterpretation is that it is, well, an interpreter layered on top of (on many systems) another interpreter. If you need your Prolog code to be really really "fast", then this approach may be "too slow". (Quotes because people love complaining about the speed of computation even in many situations where it really does not matter.) A different approach is to use code generation. Prolog programs are collections of Prolog terms; once you have written the abstract computation you want, you can write a program that takes that code, mangles it into a different form, then compiles that new form just as if you had written it by hand. So in summary, the separation you ask for is not there, but you have much more powerful tools than most other languages to implement it yourself quite easily.