6 ms·

Respectfully have to disagree. Prolog has the best features for abstraction of any language I've used, I suspect it may be near an optimal fixed point for metap

Respectfully have to disagree. Prolog has the best features for abstraction of any language I've used, I suspect it may be near an optimal fixed point for metaprogramming expression[3]. I will say the other side of that wall is breathtaking. Also not sure what you mean, CLP is a first class consideration in many Prologs, esp Scryer Prolog. Check these crazy demos out: [1] https://youtu.be/h5Xy4YjCZxM https://youtu.be/h5Xy4YjCZxM [2] https://youtu.be/5KUdEZTu06o https://youtu.be/5KUdEZTu06o Just look at this Sudoku solver code (see [2] for explanation): sudoku(Rows) :- length(Rows, 9), maplist(same_length(Rows), Rows), append(Rows, Vs), Vs ins 1..9, maplist(all_distinct, Rows), transpose(Rows, Columns), maplist(all_distinct, Columns), Rows = [As,Bs,Cs,Ds,Es,Fs,Gs,Hs,Is], blocks(As, Bs, Cs), blocks(Ds, Es, Fs), blocks(Gs, Hs, Is). blocks([], [], []). blocks([N1,N2,N3|Ns1], [N4,N5,N6|Ns2], [N7,N8,N9|Ns3]) :- all_distinct([N1,N2,N3,N4,N5,N6,N7,N8,N9]), blocks(Ns1, Ns2, Ns3). I have yet to see more elegant code in a general purpose language. [3]: https://github.com/mthom/scryer-prolog/discussions/2347#discussioncomment-11691870 https://github.com/mthom/scryer-prolog/discussions/2347#disc...

humanfromearth9 2y ago
And I have yet to understand this.
- upghost 2y ago
  Maybe watch the second link I posted?
- smarx007 2y ago
  Well, that's why language paradigms are a thing - if you are not familiar with any language in the logic paradigm but are an expert in the OO-paradigm, this could take a little bit to wrap your head around. Triska is an excellent teacher of Prolog, be sure to check out his videos linked.
- fifilura 2y ago
  I am assuming it is a close relative to Norvigs solver https://norvig.com/sudoku.html https://norvig.com/sudoku.html
javcasas 2y ago
My little pet peeve with prolog is the lack of context parameters (which can be thought as a type of abstraction). For example, imagine I'm writing a maze solver. The maze solver predicate receives obviously, but it has to pass as a parameter the maze again and again to all sub-predicates. There is no concept of "current maze", like in OO you would have with this.maze, or in Haskell you would do with a reader monad. As a result, all the "internal" predicates in a module get full of parameters all they do is pass around until some final predicate uses it to do some calculation. Either that or you do the assert/retract dance and now you have bigger problems.
- upghost 2y ago
  There are multiple ways to accomplish this, but the one that is the most straightforward is to simply make an object mapping of the type you are familiar with via AVL trees[1]. Easy way to get the "this.maze" semantics. You can get global context and local context via "blackboard"[2] semantics. However quite frankly the most powerful way to do this is not obvious because it doesn't translate well to other languages: meta-interpreters[3]. [1]: https://www.scryer.pl/assoc https://www.scryer.pl/assoc [2]: https://www.scryer.pl/iso_ext.html#bb_get/2 https://www.scryer.pl/iso_ext.html#bb_get/2 [3]: https://youtu.be/nmBkU-l1zyc https://youtu.be/nmBkU-l1zyc
  - gergo_barany 2y ago
    Could you elaborate on all of these? For [1], you would either need to pass the AVL tree around or to have it as a global (which is not wanted), and instead pass the key (the "this" context which is different for different mazes) for the context around. For [2] again you have a global table (with copying semantics as for assert/retract? or maybe without copying? the docs don't say). But again you would need to pass a key around. [3] is... yeah. I mean, sure, you could demonstrate this with a toy metainterpreter on a toy example. But do you really want to run your whole application inside a metainterpreter? One could also abuse DCG syntax, with the context being some state object instead of a DCG list. A more practical way would be Logtalk-like code generation. The most practical way would be actual Logtalk. Unfortunately, last I heard Scryer refused to host Logtalk for no real reason.
coliveira 2y ago
Yes, the OP is probably unaware of the recent advancements in Prolog. There is a set of techniques using pure Prolog that have made the language incredibly powerful compared to the techniques of the 80s and 80s. The more we use the abstract features of Prolog, the more powerful it becomes.
wslh 2y ago
Look also to sudoku solvers in Z3: [0] also papers such as "Evaluating SAT and SMT Solvers on Large-Scale Sudoku Puzzles" [1]. [0] https://github.com/grencez/grencez.dev/blob/trunk/2015/z3-solves-sudoku-20150129/sudoku.smt2 https://github.com/grencez/grencez.dev/blob/trunk/2015/z3-so... [1] https://arxiv.org/pdf/2501.08569 https://arxiv.org/pdf/2501.08569
Horffupolde 2y ago
The thing with Prolog is that it’s beautiful for solving very specific and well-defined combinatoric problems. Steer away and you hit a wall.
billfruit 2y ago
Not specifically aimed at this comment, but it looks like in most Prolog threads here, many commenters seems to plugging in Scryer Prolog, but perhaps, SWI is the most 'batteries included' and mature Prolog implementation for people not familiar with Prolog to try out .
- rscho 2y ago
  There is a bit of... let's say friction between Markus Triska (Scryer) and Jan Wielemaker (SWI), I seem to remember. The SWI people are much less attached to ISO Prolog (i.e. prone to experiment with non-ISO syntax), and some things that are fixed in the SWI implementation impeded the realization of M. Triska's projects. Generally, people tend to like the new and shiny but there's also a significant philosophical gap between Scryer and SWI. Now why would syntax be that important? It's because it directly enables homoiconicity, which is central to Prolog metaprogramming features: executing Prolog code returns a Prolog term, that can be read (just like Lisp). This is the distinctive characteristic of Prolog compared to more mainstream solvers, and what makes it 'a good programming language because it's a very dumb theorem prover'.
  - YeGoblynQueenne 2y ago
    Wot. SLD Resolution is a "very dumb" theorem prover? SLD Resolution is sound and refutation-complete and it is the basis not only of Prolog but also the most successful bunch of SAT solving algorithms in the last, dunno, several decades. "Very dumb theorem prover"!
    - rscho 2y ago
      "Prolog is an efficient programming language because it is a very stupid theorem prover." -- Richard O'Keefe
      - deleted 2y ago
        [deleted]
      - YeGoblynQueenne 2y ago
2-3-7-43-1807 2y ago
The declarative expression of the problem is elegant but even if this toy example is successfully resolved, make it a little more complicated and you'll have the interpreter ping-pong between two states infinitely. As I see it. Prolog as a language and idea is great but the existing solvers are useless for any real problem ... or you'll have to resort to cuts and memorizing states and at least partially implement an imperative solution that you yourself have to come up with. And that's totally killing the magic.
- rscho 2y ago
  Well, I mean... Prolog is an implementation of 1st order logic with syntax sugar. So basically, Prolog is incredible if your problem can be expressed within the framework, but less so if it can't. That's pretty much why there were extension attempts such as lambda Prolog.
  - 2-3-7-43-1807 2y ago
    you're simplifying the practicalities of prolog. there are many problems that you can express declaratively to the t. and yet many (all?) solvers aren't able to reduce it to a solution. the search isn't even successfully brute forcing - it will get stuck in some branch and switch endlessly between its leafs. and then it's up to you to figure that out and help the solver. even then prolog has its value but it fails at delivering the primary promise: you describe the problem, it finds a solution.
    - YeGoblynQueenne 2y ago
      That's the oldest complaint in the book about Prolog: "it's not 100% declarative". OK. So use Java. Or C. You think you'll have more declarative fun writing a Zebra Puzzle solver in C, than in Prolog? Be my guest. No, the truth is that Prolog is a unique language that is almost perfectly poised between the two extremes of beautiful but unusable formal purity and everyday programming utility. Prolog makes pragmatic choices when it has to and chooses to sacrifice declarative purity for the sake of performance and usability, because that's the only thing that makes sense considering that we have to run our programs on real computers, programmed by real programmers. And then people complain that it's no good because you can't write a solver in a purely declarative form, even though you can't even get close to the declarative features of Prolog in most other languages; except ASP, which is so declaratively pure that it doesn't even have lists. That's just a very poor criticism, poorly thought out and really meaningless in practice.
GregDavidson 2y ago
Prolog predicates are not first class values. Data structures are not abstract. Compare both with any modern lisp or better with functional languages. Mapping and filtering is awkward. Arithmetic is awkward. Indexing and search strategies are not under programmer control. Modes are awkward. Cut and dynamic assert of global facts are abominations which undermine logical reasoning. Prolog programmers often write metacircular interpreters to fix these problems which is wonderfully easy but kills efficiency. The CLP examples aren't integrated with Prolog's Horn clause resolution model, they're just libraries with strange semantics. I've been an enthusiastic Prolog programmer since the mid 1980s, attended lots of conferences, read lots of papers, etc. There have been many promising attempts to fix these problems but they've only shown up as non-standard features in specific implementations. It's similar to the "curse of Lisp" - everyone does their own thing and no consensus emerges to move the standard forward. But it could be worse if the standard were "feature oriented" rather than eliminating the limitations and flaws by cleanly generalizing the model. I study new logic programming languages avidly hoping to see a worthy successor to Prolog. So far none quite make it. Mercury might do it if it got more love.
- bmacho 2y ago
  > There have been many promising attempts to fix these problems but they've only shown up as non-standard features in specific implementations. It's similar to the "curse of Lisp" - everyone does their own thing and no consensus emerges to move the standard forward. > But it could be worse if the standard were "feature oriented" rather than eliminating the limitations and flaws by cleanly generalizing the model. Why do you feel that "eliminating the limitations" is the way forward, and not standardizing common tasks instead, making them ergonomic, uniform, fast? I don't think that more power can lead to those. Maybe ergonomics and uniformity can happen by accident if a library emerges as the default option for a task, but speed, I don't think it can.
- upghost 2y ago
  A lot of these comments don't make any sense to me. > Prolog predicates are not first class values. Predicates are trivially called, even as variables, with the `call/N` metapredicate. > Mapping and filtering is awkward In what sense? The declarative semantics...? > Arithmetic is awkward In what sense...? Have you seen clpz? > The CLP examples aren't integrated with Prolog's Horn clause resolution model In what sense...? clpz and clpb do this magnificently. > Indexing and search strategies are not under programmer control. Most ship with SLG resolution or you can write your own resolution strategy with a simple metainterpreter as an intermediate exercise -- but SLD resolution is already pretty good. In general not needing to think about the indexing and search strategies are a highlight of the declarative semantics of Prolog, its odd to see someone with a "long standing love affair with Prolog" list this as a drawback. > Modes are awkward. Modal programming is a defining feature of Prolog. Tell me more about this "long standing love affair", again? > I've been an enthusiastic Prolog programmer since the mid 1980s If you are still struggling with mapping, filtering, arithmetic, `call/N`, and CLP in Prolog after nearly 45 years of "enthusiastic" programming, I'd highly recommend checking out Triska's Power of Prolog videos for some guidance, I think you will find them very illuminating. https://youtube.com/@thepowerofprolog https://youtube.com/@thepowerofprolog
horsh1 2y ago
You have "Rows" repeated eight times in this short snippet. You have all the rest of your variables as two letter names. It feels low level, almost like Fortran.
- qu1j0t3 2y ago
  Speaking of Fortran: please paste the equivalent JavaScript

humanfromearth9 2y ago

And I have yet to understand this.

upghost 2y ago
Maybe watch the second link I posted?
smarx007 2y ago
Well, that's why language paradigms are a thing - if you are not familiar with any language in the logic paradigm but are an expert in the OO-paradigm, this could take a little bit to wrap your head around. Triska is an excellent teacher of Prolog, be sure to check out his videos linked.
fifilura 2y ago
I am assuming it is a close relative to Norvigs solver https://norvig.com/sudoku.html https://norvig.com/sudoku.html

javcasas 2y ago

My little pet peeve with prolog is the lack of context parameters (which can be thought as a type of abstraction). For example, imagine I'm writing a maze solver. The maze solver predicate receives obviously, but it has to pass as a parameter the maze again and again to all sub-predicates. There is no concept of "current maze", like in OO you would have with this.maze, or in Haskell you would do with a reader monad. As a result, all the "internal" predicates in a module get full of parameters all they do is pass around until some final predicate uses it to do some calculation. Either that or you do the assert/retract dance and now you have bigger problems.

upghost 2y ago
There are multiple ways to accomplish this, but the one that is the most straightforward is to simply make an object mapping of the type you are familiar with via AVL trees[1]. Easy way to get the "this.maze" semantics. You can get global context and local context via "blackboard"[2] semantics. However quite frankly the most powerful way to do this is not obvious because it doesn't translate well to other languages: meta-interpreters[3]. [1]: https://www.scryer.pl/assoc https://www.scryer.pl/assoc [2]: https://www.scryer.pl/iso_ext.html#bb_get/2 https://www.scryer.pl/iso_ext.html#bb_get/2 [3]: https://youtu.be/nmBkU-l1zyc https://youtu.be/nmBkU-l1zyc
- gergo_barany 2y ago
  Could you elaborate on all of these? For [1], you would either need to pass the AVL tree around or to have it as a global (which is not wanted), and instead pass the key (the "this" context which is different for different mazes) for the context around. For [2] again you have a global table (with copying semantics as for assert/retract? or maybe without copying? the docs don't say). But again you would need to pass a key around. [3] is... yeah. I mean, sure, you could demonstrate this with a toy metainterpreter on a toy example. But do you really want to run your whole application inside a metainterpreter? One could also abuse DCG syntax, with the context being some state object instead of a DCG list. A more practical way would be Logtalk-like code generation. The most practical way would be actual Logtalk. Unfortunately, last I heard Scryer refused to host Logtalk for no real reason.

coliveira 2y ago

Yes, the OP is probably unaware of the recent advancements in Prolog. There is a set of techniques using pure Prolog that have made the language incredibly powerful compared to the techniques of the 80s and 80s. The more we use the abstract features of Prolog, the more powerful it becomes.

wslh 2y ago

Look also to sudoku solvers in Z3: [0] also papers such as "Evaluating SAT and SMT Solvers on Large-Scale Sudoku Puzzles" [1]. [0] https://github.com/grencez/grencez.dev/blob/trunk/2015/z3-solves-sudoku-20150129/sudoku.smt2 https://github.com/grencez/grencez.dev/blob/trunk/2015/z3-so... [1] https://arxiv.org/pdf/2501.08569 https://arxiv.org/pdf/2501.08569

Horffupolde 2y ago

The thing with Prolog is that it’s beautiful for solving very specific and well-defined combinatoric problems. Steer away and you hit a wall.

billfruit 2y ago

Not specifically aimed at this comment, but it looks like in most Prolog threads here, many commenters seems to plugging in Scryer Prolog, but perhaps, SWI is the most 'batteries included' and mature Prolog implementation for people not familiar with Prolog to try out .

rscho 2y ago
There is a bit of... let's say friction between Markus Triska (Scryer) and Jan Wielemaker (SWI), I seem to remember. The SWI people are much less attached to ISO Prolog (i.e. prone to experiment with non-ISO syntax), and some things that are fixed in the SWI implementation impeded the realization of M. Triska's projects. Generally, people tend to like the new and shiny but there's also a significant philosophical gap between Scryer and SWI. Now why would syntax be that important? It's because it directly enables homoiconicity, which is central to Prolog metaprogramming features: executing Prolog code returns a Prolog term, that can be read (just like Lisp). This is the distinctive characteristic of Prolog compared to more mainstream solvers, and what makes it 'a good programming language because it's a very dumb theorem prover'.
- YeGoblynQueenne 2y ago
  Wot. SLD Resolution is a "very dumb" theorem prover? SLD Resolution is sound and refutation-complete and it is the basis not only of Prolog but also the most successful bunch of SAT solving algorithms in the last, dunno, several decades. "Very dumb theorem prover"!
  - rscho 2y ago
    "Prolog is an efficient programming language because it is a very stupid theorem prover." -- Richard O'Keefe
    - deleted 2y ago
      [deleted]
    - YeGoblynQueenne 2y ago

2-3-7-43-1807 2y ago

The declarative expression of the problem is elegant but even if this toy example is successfully resolved, make it a little more complicated and you'll have the interpreter ping-pong between two states infinitely. As I see it. Prolog as a language and idea is great but the existing solvers are useless for any real problem ... or you'll have to resort to cuts and memorizing states and at least partially implement an imperative solution that you yourself have to come up with. And that's totally killing the magic.

rscho 2y ago
Well, I mean... Prolog is an implementation of 1st order logic with syntax sugar. So basically, Prolog is incredible if your problem can be expressed within the framework, but less so if it can't. That's pretty much why there were extension attempts such as lambda Prolog.
- 2-3-7-43-1807 2y ago
  you're simplifying the practicalities of prolog. there are many problems that you can express declaratively to the t. and yet many (all?) solvers aren't able to reduce it to a solution. the search isn't even successfully brute forcing - it will get stuck in some branch and switch endlessly between its leafs. and then it's up to you to figure that out and help the solver. even then prolog has its value but it fails at delivering the primary promise: you describe the problem, it finds a solution.
  - YeGoblynQueenne 2y ago
    That's the oldest complaint in the book about Prolog: "it's not 100% declarative". OK. So use Java. Or C. You think you'll have more declarative fun writing a Zebra Puzzle solver in C, than in Prolog? Be my guest. No, the truth is that Prolog is a unique language that is almost perfectly poised between the two extremes of beautiful but unusable formal purity and everyday programming utility. Prolog makes pragmatic choices when it has to and chooses to sacrifice declarative purity for the sake of performance and usability, because that's the only thing that makes sense considering that we have to run our programs on real computers, programmed by real programmers. And then people complain that it's no good because you can't write a solver in a purely declarative form, even though you can't even get close to the declarative features of Prolog in most other languages; except ASP, which is so declaratively pure that it doesn't even have lists. That's just a very poor criticism, poorly thought out and really meaningless in practice.

GregDavidson 2y ago

Prolog predicates are not first class values. Data structures are not abstract. Compare both with any modern lisp or better with functional languages. Mapping and filtering is awkward. Arithmetic is awkward. Indexing and search strategies are not under programmer control. Modes are awkward. Cut and dynamic assert of global facts are abominations which undermine logical reasoning. Prolog programmers often write metacircular interpreters to fix these problems which is wonderfully easy but kills efficiency. The CLP examples aren't integrated with Prolog's Horn clause resolution model, they're just libraries with strange semantics. I've been an enthusiastic Prolog programmer since the mid 1980s, attended lots of conferences, read lots of papers, etc. There have been many promising attempts to fix these problems but they've only shown up as non-standard features in specific implementations. It's similar to the "curse of Lisp" - everyone does their own thing and no consensus emerges to move the standard forward. But it could be worse if the standard were "feature oriented" rather than eliminating the limitations and flaws by cleanly generalizing the model. I study new logic programming languages avidly hoping to see a worthy successor to Prolog. So far none quite make it. Mercury might do it if it got more love.

bmacho 2y ago
> There have been many promising attempts to fix these problems but they've only shown up as non-standard features in specific implementations. It's similar to the "curse of Lisp" - everyone does their own thing and no consensus emerges to move the standard forward. > But it could be worse if the standard were "feature oriented" rather than eliminating the limitations and flaws by cleanly generalizing the model. Why do you feel that "eliminating the limitations" is the way forward, and not standardizing common tasks instead, making them ergonomic, uniform, fast? I don't think that more power can lead to those. Maybe ergonomics and uniformity can happen by accident if a library emerges as the default option for a task, but speed, I don't think it can.
upghost 2y ago
A lot of these comments don't make any sense to me. > Prolog predicates are not first class values. Predicates are trivially called, even as variables, with the `call/N` metapredicate. > Mapping and filtering is awkward In what sense? The declarative semantics...? > Arithmetic is awkward In what sense...? Have you seen clpz? > The CLP examples aren't integrated with Prolog's Horn clause resolution model In what sense...? clpz and clpb do this magnificently. > Indexing and search strategies are not under programmer control. Most ship with SLG resolution or you can write your own resolution strategy with a simple metainterpreter as an intermediate exercise -- but SLD resolution is already pretty good. In general not needing to think about the indexing and search strategies are a highlight of the declarative semantics of Prolog, its odd to see someone with a "long standing love affair with Prolog" list this as a drawback. > Modes are awkward. Modal programming is a defining feature of Prolog. Tell me more about this "long standing love affair", again? > I've been an enthusiastic Prolog programmer since the mid 1980s If you are still struggling with mapping, filtering, arithmetic, `call/N`, and CLP in Prolog after nearly 45 years of "enthusiastic" programming, I'd highly recommend checking out Triska's Power of Prolog videos for some guidance, I think you will find them very illuminating. https://youtube.com/@thepowerofprolog https://youtube.com/@thepowerofprolog

horsh1 2y ago

You have "Rows" repeated eight times in this short snippet. You have all the rest of your variables as two letter names. It feels low level, almost like Fortran.

qu1j0t3 2y ago
Speaking of Fortran: please paste the equivalent JavaScript