4 ms·

miniKanren is a replacement for a Prolog like a shitty tree-walking sexpr interpreter that doesn't even have modules is a replacement for Racket. I don't even k

miniKanren is a replacement for a Prolog like a shitty tree-walking sexpr interpreter that doesn't even have modules is a replacement for Racket. I don't even know what to say to you for suggesting that, frankly. Anyways the embedded inference engine as an idea failed a long time ago, Americans convinced themselves it was the way to do things and just refused to ever let it go. It's just extra baggage on the important bit, which is the symbolic computation. miniKanren has a niche more in line with a theorem solver.

BoingBoomTschak 2mo ago
Instead of us two milling about: https://minikanren.org/minikanren-and-prolog.html https://minikanren.org/minikanren-and-prolog.html (and this is both informed and pretty impartial from what I can read)
- YeGoblynQueenne 2mo ago
  I don't see where the above says that Prolog is a "poor general purpose language"? I'd instead say that claim is incompatible with the following paragraphs that rather sing the praises of Prolog as a programming language: Prolog is one of the two classic languages for symbolic artificial intelligence programming (the other classic language being Lisp). Prolog excels at implementing symbolic rule-based systems in which declarative knowledge is encoded in first-order logic. The language is optimized for expressiveness and efficiency for these types of applications, sometimes at the expense of logical purity. For example, by default Prolog does not use the "occur check" in unification. From a math/logic standpoint, this version of unification is incorrect. However, the occur check is expensive, and in most cases the lack of the occur check is not a problem. This is a very pragmatic design decision, as is Prolog's use of depth-first search, and use of cut (!) to control backtracking. I'm sure these decisions were absolutely necessary when running on the hardware of the 1970s, and today are very useful when working on large problems, and when dealing with huge (often infinite!) search spaces. Prolog supports many "extra-logical" or "non-logical" features, including cut, assert and retract, projection of variables for arithmetic using is, and so forth. Many of these features make it easier to express complex control flow, and to manipulate Prolog's global database of facts. One very interesting feature of Prolog is that Prolog code is itself stored in the global database of facts, and can be queried against at run time. This makes it trivial to write meta-interpreters that modify the behavior of Prolog code under interpretation. For example, it is possible to encode breadth-first search in Prolog using a meta-interpreter that changes the search order. This is an extremely powerful technique that is not well known outside of the Prolog world. 'The Art of Prolog' describes this technique in detail. Tremendous effort has gone into improving Prolog implementations, most of which are based on the Warren Abstract Machine (WAM). The WAM uses a side-effecting model in which values are destructively assigned to logic variables, with these side-effects being undone upon backtracking. Many features can be added to Prolog by extending the instructions of the WAM. One disadvantage of this approach is that Prolog implementation papers can be difficult to read without a solid understanding of the WAM. On the other hand, Prolog implementer have a common model for discussing implementation issues. There has been a great deal of research in parallel Prolog, culminating in Andorra Prolog in the 1990s. At least some of these ideas live on in Ciao Prolog. (Ciao Prolog is full of interesting ideas, many of which go far beyond the Prolog standard.) Prolog has a beautiful unification-based "pattern-matching"-style syntax that results in very succinct programs. Prologers love their syntax, just like Lispers love their s-expressions. Prolog also has a large library of standard predicates. Due to all of the engineering that has gone into making the WAM fast, there are very capable and mature Prolog implementations. As a result, many large knowledge-based systems have been written entirely in Prolog. So, why do you say that Prolog is a "poor general purpose language"?
  - BoingBoomTschak 2mo ago
    That link wasn't an argument to support my claim, just a related comparison. > So, why do you say that Prolog is a "poor general purpose language"? Big disclaimer: I have almost no Prolog experience beyond a distant university class, so I've no idea what's possible with a pragmatic impl. like SWI-Prolog. Still, this is my uninformed "Emacs vs vim tier" opinion. For the same reason as most other people do so: when you're not working with problems suited for it (most of them), Prolog loses much of its power and intuitiveness to become a barebones functional PL without much going for it (needing lots of extensions beyond ISO); bit like Erlang outside distributed/high availability situations. The other way is going full "hammer and nails" and try to hamfist every problem into a logic/declarative one.
    - YeGoblynQueenne 2mo ago
      That's not my experience of Prolog and I can't see how it's yours if you have "almost no Prolog experience" etc. EDIT: I don't want to get into a holy flamewar (vim vs emacs? Oh dear) but I've heard that criticism before. I think the reason is that there's a kind of program that is absolutely trivial to write in Prolog: business logic, rules engines, etc, anything where you can write out the program logic as a set of facts and rules. I mean duh. A Prolog program is a set of facts and rules. But at that point you're* not even trying to use the language. Then of course, if you try to do something more complicated it will take more effort and you will need to really understand how Prolog works; which is not trivial. So I think it's a bit like mathematics. Yeah, if you just want to add 1 and 1, it's easy. If you want to calculate the amount of fuel it will take to fly to the moon and back, it takes considerably more effort. You can see it as maths being "easy for the easy things but hard for the hard things", but it's just that the hard things are hard and take more work, not the fault of maths as such. __________ * "You" in the abstract, not you personally.
    - ux266478 2mo ago
      > Prolog loses much of its power and intuitiveness to become a barebones functional PL How do you mean? The grain of Prolog isn't functional in the slightest, and it's not a barebones language by any means. It comes with a massive standard library, extensive tooling, etc. Real Prolog implementations come with their own UI toolkit, IDE, etc. > without much going for it There's plenty of going for it, there's frankly nothing else like it. It has all the same mutable grammar as a Lisp, and a computational model that's much, much better at language-processing. Bi-directional structural matching through unification, execution path natively handled by backtracking, and DCGs as part of the standard, etc. All of these things contribute to an incredibly unique superpower that makes implementing sound DSLs of any type-0 grammar incredibly trivial. More so than any other language, including Lisp! This is all incredibly superficial too. DCGs are a lot more general than just describing a foreign grammar, and they're a single example of what you can use Prolog's mutable grammar to do (DCGs are just a macro!) > (needing lots of extensions beyond ISO) Which is true of all industrial grade tools. Look at LispWorks and SBCL, look at Racket. They don't stop at the standard, do they? The ISO standard for Prolog is a massive beast, much larger than you think it is, and is plenty useful by itself. But it's hardly meaningful that serious tools go beyond the standard, or provide ways to break it. That's a universal for serious tools. Here's the thing, even putting aside all the architectural choices of miniKanren that make it inappropriate for symbolic AI (immutability, occurs-check, etc.) it is what you accuse Prolog of being: barebones. To this date, I don't think a single real debugger exists for any miniKanren implementation. It's always the most hacky, unsound, "why care about it" neglect. All other issues aside, this one (of many) effectively kills it. We're not talking an issue of needing to build up intuition for an alien execution model, we're talking the complete and total lack of introspection for something we're trying to build a complex system with. In Symbolic AI, your inference system cannot be a second class citizen. It is where the overwhelming majority of your work lives. It is where all the complex machinery is built. It requires a real development system built around the inference engine, because that thing is your computer. You need a debugger. You need an IDE. There's a reason LispWorks puts so much effort into KnowledgeWorks, why it comes with so much stuff. That's why corporations pay out the nose for enterprise licenses. You can't have a serious, usable system without serious tools.

BoingBoomTschak 2mo ago

Instead of us two milling about: https://minikanren.org/minikanren-and-prolog.html https://minikanren.org/minikanren-and-prolog.html (and this is both informed and pretty impartial from what I can read)

YeGoblynQueenne 2mo ago
I don't see where the above says that Prolog is a "poor general purpose language"? I'd instead say that claim is incompatible with the following paragraphs that rather sing the praises of Prolog as a programming language: Prolog is one of the two classic languages for symbolic artificial intelligence programming (the other classic language being Lisp). Prolog excels at implementing symbolic rule-based systems in which declarative knowledge is encoded in first-order logic. The language is optimized for expressiveness and efficiency for these types of applications, sometimes at the expense of logical purity. For example, by default Prolog does not use the "occur check" in unification. From a math/logic standpoint, this version of unification is incorrect. However, the occur check is expensive, and in most cases the lack of the occur check is not a problem. This is a very pragmatic design decision, as is Prolog's use of depth-first search, and use of cut (!) to control backtracking. I'm sure these decisions were absolutely necessary when running on the hardware of the 1970s, and today are very useful when working on large problems, and when dealing with huge (often infinite!) search spaces. Prolog supports many "extra-logical" or "non-logical" features, including cut, assert and retract, projection of variables for arithmetic using is, and so forth. Many of these features make it easier to express complex control flow, and to manipulate Prolog's global database of facts. One very interesting feature of Prolog is that Prolog code is itself stored in the global database of facts, and can be queried against at run time. This makes it trivial to write meta-interpreters that modify the behavior of Prolog code under interpretation. For example, it is possible to encode breadth-first search in Prolog using a meta-interpreter that changes the search order. This is an extremely powerful technique that is not well known outside of the Prolog world. 'The Art of Prolog' describes this technique in detail. Tremendous effort has gone into improving Prolog implementations, most of which are based on the Warren Abstract Machine (WAM). The WAM uses a side-effecting model in which values are destructively assigned to logic variables, with these side-effects being undone upon backtracking. Many features can be added to Prolog by extending the instructions of the WAM. One disadvantage of this approach is that Prolog implementation papers can be difficult to read without a solid understanding of the WAM. On the other hand, Prolog implementer have a common model for discussing implementation issues. There has been a great deal of research in parallel Prolog, culminating in Andorra Prolog in the 1990s. At least some of these ideas live on in Ciao Prolog. (Ciao Prolog is full of interesting ideas, many of which go far beyond the Prolog standard.) Prolog has a beautiful unification-based "pattern-matching"-style syntax that results in very succinct programs. Prologers love their syntax, just like Lispers love their s-expressions. Prolog also has a large library of standard predicates. Due to all of the engineering that has gone into making the WAM fast, there are very capable and mature Prolog implementations. As a result, many large knowledge-based systems have been written entirely in Prolog. So, why do you say that Prolog is a "poor general purpose language"?
- BoingBoomTschak 2mo ago
  That link wasn't an argument to support my claim, just a related comparison. > So, why do you say that Prolog is a "poor general purpose language"? Big disclaimer: I have almost no Prolog experience beyond a distant university class, so I've no idea what's possible with a pragmatic impl. like SWI-Prolog. Still, this is my uninformed "Emacs vs vim tier" opinion. For the same reason as most other people do so: when you're not working with problems suited for it (most of them), Prolog loses much of its power and intuitiveness to become a barebones functional PL without much going for it (needing lots of extensions beyond ISO); bit like Erlang outside distributed/high availability situations. The other way is going full "hammer and nails" and try to hamfist every problem into a logic/declarative one.
  - YeGoblynQueenne 2mo ago
    That's not my experience of Prolog and I can't see how it's yours if you have "almost no Prolog experience" etc. EDIT: I don't want to get into a holy flamewar (vim vs emacs? Oh dear) but I've heard that criticism before. I think the reason is that there's a kind of program that is absolutely trivial to write in Prolog: business logic, rules engines, etc, anything where you can write out the program logic as a set of facts and rules. I mean duh. A Prolog program is a set of facts and rules. But at that point you're* not even trying to use the language. Then of course, if you try to do something more complicated it will take more effort and you will need to really understand how Prolog works; which is not trivial. So I think it's a bit like mathematics. Yeah, if you just want to add 1 and 1, it's easy. If you want to calculate the amount of fuel it will take to fly to the moon and back, it takes considerably more effort. You can see it as maths being "easy for the easy things but hard for the hard things", but it's just that the hard things are hard and take more work, not the fault of maths as such. __________ * "You" in the abstract, not you personally.
  - ux266478 2mo ago
    > Prolog loses much of its power and intuitiveness to become a barebones functional PL How do you mean? The grain of Prolog isn't functional in the slightest, and it's not a barebones language by any means. It comes with a massive standard library, extensive tooling, etc. Real Prolog implementations come with their own UI toolkit, IDE, etc. > without much going for it There's plenty of going for it, there's frankly nothing else like it. It has all the same mutable grammar as a Lisp, and a computational model that's much, much better at language-processing. Bi-directional structural matching through unification, execution path natively handled by backtracking, and DCGs as part of the standard, etc. All of these things contribute to an incredibly unique superpower that makes implementing sound DSLs of any type-0 grammar incredibly trivial. More so than any other language, including Lisp! This is all incredibly superficial too. DCGs are a lot more general than just describing a foreign grammar, and they're a single example of what you can use Prolog's mutable grammar to do (DCGs are just a macro!) > (needing lots of extensions beyond ISO) Which is true of all industrial grade tools. Look at LispWorks and SBCL, look at Racket. They don't stop at the standard, do they? The ISO standard for Prolog is a massive beast, much larger than you think it is, and is plenty useful by itself. But it's hardly meaningful that serious tools go beyond the standard, or provide ways to break it. That's a universal for serious tools. Here's the thing, even putting aside all the architectural choices of miniKanren that make it inappropriate for symbolic AI (immutability, occurs-check, etc.) it is what you accuse Prolog of being: barebones. To this date, I don't think a single real debugger exists for any miniKanren implementation. It's always the most hacky, unsound, "why care about it" neglect. All other issues aside, this one (of many) effectively kills it. We're not talking an issue of needing to build up intuition for an alien execution model, we're talking the complete and total lack of introspection for something we're trying to build a complex system with. In Symbolic AI, your inference system cannot be a second class citizen. It is where the overwhelming majority of your work lives. It is where all the complex machinery is built. It requires a real development system built around the inference engine, because that thing is your computer. You need a debugger. You need an IDE. There's a reason LispWorks puts so much effort into KnowledgeWorks, why it comes with so much stuff. That's why corporations pay out the nose for enterprise licenses. You can't have a serious, usable system without serious tools.