Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn Prolog Now (2006)

lpn.swi-prolog.org

Post reply on HN
Print view View original

221–230 of 251 posts

Re: Learn Prolog Now (2006)

#221

Post by cubefox »

scotty79 wrote: post #212
cubefox wrote: post #201

Earlier quoted context omitted.

> It's not really false I think. It's 'no', which is an answer to a question "Do I know this to be true?" I don't think so, because in this case both x and not-x could be "no", but I think in Prolog, if x is "no", not-x is "yes", even if neither is known to be true. It's not a three-valued logic that doesn't adhere to the law of the excluded middle.

If x is "no" (I do not know this to be true) then not-x is "yes" (I do know this to be true). So negation still works as usual. "Yes" is not "true" but rather "provably true". And "no" is not "false" but rather "not provably true". Third sensible value in this framework (which I think Prolog doesn't have) would be "false" meaning "it's provably false" ("the opposite of it is provably true"). To be frank I think Prolo…

> If x is "no" (I do not know this to be true) then not-x is "yes" (I do know this to be true). So negation still works as usual.

As I said though, that doesn't make sense. Because if I don't know x to be true because it is not mentioned in the knowledge base, I also don't know not-x to be true. So both would have to be "no". But they aren't. Therefore the knowledge interpretation is incorrect. Knowledge wouldn't be closed under negation. If you don't know something to be true, that doesn't imply that you know it to be false.

Re: Learn Prolog Now (2006)

#222

Post by johnisgood »

jabbywocker wrote: post #219
johnisgood wrote: post #192

Earlier quoted context omitted.

Yeah, read it in another comment. Why do you think doing calculations in your head is brute-forcing? Many people can do it flawlessly, without even knowing of these "tricks". They just know. Is that brute-force?

[flagged]

You are not replying to what I said. I am not going to repeat myself, see the parent comment you replied to.

Re: Learn Prolog Now (2006)

#223

Post by vidarh »

exasperaited wrote: post #83
vidarh wrote: post #18

Earlier quoted context omitted.

I also found it mindbending. But some parts, like e.g. the cut operator is something I've copied several times over for various things. A couple of prototype parser generators for example - allowing backtracking, but using a cut to indicate when backtracking is an error can be quite helpful.

"Keep your exclamation points under control. You are allowed no more than two or three per 100,000 words of prose." Elmore Leonard, on writing. But he might as well have been talking about the cut operator. At uni I had assignments where we were simply not allowed to use it.

That may make sense for Prolog code - I don't know Prolog enough to say. But the places I like to use it, it significantly simplified code by letting me write grammars with more local and specific error reporting.

That is, instead of continuing to backtrack, I'd use a cut-like operator to say "if you backtrack past this, then the error is here, and btw. (optionally) here is a nicer error message".

This could of course alter semantics. E.g. if I had a rule "expr ::= (foo ! bar) | (foo baz), foo baz would never get satisfied, whereas with "expr ::= (foo bar) | (foo baz)" it could. (And in that example, it'd be totally inappropriate in my parser generator too)

I'm guessing the potential to have non-local effects on the semantics is why you'd consider it problematic in Prolog? I can see it would be problematic if the cut is hidden away from where it would affect you.

In my use, the grammar files would typically be a couple of hundred lines at most, and the grammar itself well understood, and it was used explicitly to throw an error, so you'd instantly know.

There are (at least) two ways of improving on that, which I didn't bother with: I could use it to say "push the error message and location" and pop those errors if a given subtree of the parse was optional. Or I could validate that these operators don't occur in rules that are used in certain ways.

But in practice in this use I never ended up with big enough code that it seemed worth it, and would happily litter the grammars with lots of them.

Re: Learn Prolog Now (2006)

#224

Post by alfonsodev »

disambiguation wrote: post #40

I am once again shilling the idea that someone should find a way to glue Prolog and LLMs together for better reasoning agents. https://news.ycombinator.com/context?id=43948657 Thesis: 1. LLMs are bad at counting the number of r's in strawberry. 2. LLMs are good at writing code that counts letters in a string. 3. LLMs are bad at solving reasoning problems. 4. Prolog is good at solving reasoning problems. 5. ??? 6. LLM…

I've been thinking a lot about this, and I want to build the following experiment, in case anyone is interested:

The experiment is about putting an LLM to play plman[0] with and without prolog help.

plman is a pacman like game for learning prolog, it was written by profesor Francisco J. Gallego from Alicante University to teach logic subject in computer science.

Basically you write solution in prolog for a map, and plman executes it step by step so you can see visually the pacman (plman) moving around the maze eating and avoiding ghost and other traps.

There is an interesting dynamic about finding keys for doors and timing based traps.

There are different levels of complexity, and you can also write easily your maps, since they are just ascii characters in a text file.

I though this was the perfect project to visually explain my coworkers the limit of LLM "reasoning" and what is symbolic reasoning.

So far I hooked ChatGPT API to try to solve scenarios, and it fails even with substancial amount of retries. That's what I was expecting.

The next thing would be to write a mcp tool so that the LLM can navigate the problem by using the tool, but here is where I need guidance.

I'm not sure about the best dynamic to prove the usefulness of prolog in a way that goes beyond what context retrieval or db query could do.

I'm not sure if the LLM should write the prolog solution. I want to avoid to build something trivial like the LLM asking for the steps, already solved, so my intuition is telling me that I need some sort of virtual joystick mcp to hide prolog from the LLM, so the LLM could have access to the current state of the screen, and questions like what would be my position if I move up ? What's the position of the ghost in next move ? where is the door relative to my current position ?

I don't have academic background to design this experiment properly. Would be great if anyone is interested to work together on this, or give me some advice.

Prior work pending on my reading list:

- LoRP: LLM-based Logical Reasoning via Prolog [1]

- A Pipeline of Neural-Symbolic Integration to Enhance Spatial Reasoning in Large Language Models [2]

- [0] https://github.com/Matematicas1UA/plman/blob/master/README.m...

- [1] https://www.sciencedirect.com/science/article/abs/pii/S09507...

- [2] https://arxiv.org/html/2411.18564v1

Re: Learn Prolog Now (2006)

#225

Post by scotty79 »

cubefox wrote: post #221
scotty79 wrote: post #212

Earlier quoted context omitted.

If x is "no" (I do not know this to be true) then not-x is "yes" (I do know this to be true). So negation still works as usual. "Yes" is not "true" but rather "provably true". And "no" is not "false" but rather "not provably true". Third sensible value in this framework (which I think Prolog doesn't have) would be "false" meaning "it's provably false" ("the opposite of it is provably true"). To be frank I think Prolo…

> If x is "no" (I do not know this to be true) then not-x is "yes" (I do know this to be true). So negation still works as usual. As I said though, that doesn't make sense. Because if I don't know x to be true because it is not mentioned in the knowledge base, I also don't know not-x to be true. So both would have to be "no". But they aren't. Therefore the knowledge interpretation is incorrect. Knowledge wouldn't be…

You are right. If X is 'no' then not-X wouldn't necessarily be "yes".

After looking around I see that Prolog recognizes some nuance around not: https://en.wikipedia.org/wiki/Prolog#Negation

And aldready deprecated one 'not' operator:

https://www.swi-prolog.org/pldoc/man?predicate=not/1

Look at how they are not using not, but rather "not provable".

I'm not sure if Prolog has straight up negation behaving in binary arithmetic way.

Re: Learn Prolog Now (2006)

#226

Post by scotty79 »

hunterpayne wrote: post #164
Jtsummers wrote: post #161

Earlier quoted context omitted.

You seem to be confusing two different things: What is easily or natively expressed in the language, and what can be expressed in the language. You can create a logical equivalent of the cut operator in Fortran if you wanted to, but there's no native mechanism or operator to rely on. The languages possess the same computing "power", the difference is not in what they can compute which is your claim with "there are th…

> You can create a logical equivalent of the cut operator in Fortran if you wanted to In isolation, no you can't. You could implement a Prolog interpreter in Fortran however. And if you did that, you would be able to write a cut operator because then you are interacting directly with Prolog's machinery. Part of the definition of the cut operator involves changing how code around it behaves. You can't do this with For…

I think cut operator doesn't make sense for any other language because prolog doesn't execude code linerily. It executes it with depth first search with backtracking. Only when you have a thing that walks the tree it makes sense to have a cut operator that prevents backtracking at some spots.

Re: Learn Prolog Now (2006)

#227

Post by jodrellblank »

YeGoblynQueenne wrote: post #217
jodrellblank wrote: post #213

Earlier quoted context omitted.

Clearly people write parsers in C and C++ and Pascal and OCAML, etc. What does it mean to come in with "the reason you can write parsers with Prolog..."? I'm not claiming that reason is incorrect, I'm handwaving it away as irrelevant and academic. Like saying that Lisp map() is better than Python map() because Lisp map is based on formal Lambda Calculus and Python map is an inferior imitation for blub programmers. Wh…

With Prolog, the proof is carried out by the computer, not a human. A human writes up a theory and a theorem and the computer proves the theorem with respect to the theory. So I ask again, how is carrying out a proof not reasoning? >> I'm not claiming that reason is incorrect, I'm handwaving it away as irrelevant and academic. That's not a great way to have a discussion.

The word "reason" came into this thread with the original comment:

    3. LLMs are bad at solving reasoning problems.

    4. Prolog is good at solving reasoning problems.
I agree with you. In Prolog "?- 1=1." is reasoning by definition. Then 4. becomes "LLMs should emit Prolog because Prolog is good at executing Prolog code".

I think that's not a useful place to be, so I was trying to head off going there. But now I'll go with you - I agree it IS reasoning - can you please support your case that "executing Prolog code is reasoning" makes Prolog more useful for LLMs to emit than Python?

Re: Learn Prolog Now (2006)

#228

Post by Izkata »

johnisgood wrote: post #222
jabbywocker wrote: post #219

Earlier quoted context omitted.

[flagged]

You are not replying to what I said. I am not going to repeat myself, see the parent comment you replied to.

Your original comment completely missed the point of what it was replying to, you phrased it like you were correcting them but you were actually in agreement and didn't seem to realize it. They tried to clarify when you asked and when you responded you assumed they had the opposite viewpoint from what they actually have.

Re: Learn Prolog Now (2006)

#229

Post by arein3 »

a96 wrote: post #200
arein3 wrote: post #25

We had it in university courses and it seemed useless. DSL for backtracking.

Yes. As an add-on or library, it could be useful, but as a language it's just a forgotten dead end.

And for some cases it's easier to understand if you write the backtracking yourself, and can edit/debug it. That is in case you write readable code professionally, as such algorhythms are not very intuitive for a person who sees it first time.

Re: Learn Prolog Now (2006)

#230

Post by Jtsummers »

scotty79 wrote: post #226
hunterpayne wrote: post #164

Earlier quoted context omitted.

> You can create a logical equivalent of the cut operator in Fortran if you wanted to In isolation, no you can't. You could implement a Prolog interpreter in Fortran however. And if you did that, you would be able to write a cut operator because then you are interacting directly with Prolog's machinery. Part of the definition of the cut operator involves changing how code around it behaves. You can't do this with For…

I think cut operator doesn't make sense for any other language because prolog doesn't execude code linerily. It executes it with depth first search with backtracking. Only when you have a thing that walks the tree it makes sense to have a cut operator that prevents backtracking at some spots.

I don't think the person you responded to knows what the cut operator is, or they wouldn't have written any of their nonsense comments. They seem to think that it's some magical thing and not, as you wrote, a way to stop backtracking from going back through some point. You can implement that in any appropriate search system in any language. It might not be an operator, but it would carry the same meaning and effect.
Post reply on HN