My question is - How can I fail on the fisrt do_somthig (print FAIL only once) without backtracing and than continue to next do_something and print SUCCESS?
What are you really trying to achieve? If you provide some context, it might become easier to help. Code with cuts and fails in it isnāt wrong but maybe those are unnecessary. Either way, I am struggling to understand the purpose of the code. The operational or logical meaning of the code is secondary to the purpose of the code.
I tried to explain in another post of mine, but I opened a new one. Here is the refernce
Assume I have some facts that if they happened, It should fail (like blacklist of facts).
I want to check for the new fact that I entered if it in the blacklist.
But now, for this new fact, I have a few checks that should made be done.
So it is important for me to find all failures.
Yes, this is all fine, but I donāt really understand why are you doing all this?
So, if you want to print āHEREā once, you can just like, print it once. Like this:
format("HERE~n", [])
I understand that this is not what you mean, but I donāt understand what it is that you are trying to achieve.
Printing out from predicates is anyway not a good idea. It can help while you debug, if you donāt want to learn how to use the debugger, but otherwise it is not too useful.
This brings me back to a topic that I have written about before in this forum. Homework help on a forum like this is almost always a waste of everyoneās time. The student was given a lecture, lecture material, and exercises; when they struggle with the exercises, they come and ask for help here, which is perfectly fine.
HOWEVER, the student does not provide the lecture, the lecture material, and the original problem statement; instead, we get glimpses of the studentās struggle to solve the problem. We offer detailed help that is just as incomprehensible to the student as is the studentās question to us. The help we are trying to provide is probably also just misleading.
If you want some useful advice: take your questions to the person who made you solve those problems. If they cannot or refuse to help you, your problems are outside of the realm of programming.
You are right with your attitude.
The main reason I donāt give the whole problem, because itās not so defined, due to the fact I create them and chose how to implement the way to solve them.
My current problem is backtracking issue, but maybe itās more than that
In my little knowledge it feel to me that my problems are not complicated, it seems I wrong.
Prolog is very different from other functional languages such as python.
Iām trying to figure it out, and I doing it by self, with no course.
Your answers and guidance helping me a lot, although I donāt understand everything perfectly.
It seems you have a lot experience and for me is the right place to learn from.
I will try to change my approach and solve it again.
If I will handle with the same problem again, I will try to defined what Iām trying to achieve.
What do you mean by āfunctional languageā here? Neither Prolog nor Python is a āfunctional languageā in the common use of the word. They both function but this is something different I guess?
Well thank you but a forum like this is not necessarily a good place to learn from. If you have a specific question and you are able to formulate a question, you might get lucky and get a useful answer. For homework, in my limited experience, asking strangers on the internet is rarely useful
Again, my advice: look carefully through the lectures and the rest of the material that you have received. Unless your instructor is being difficult on purpose, all the answers you need are there, hidden in plain sight.
I donāt have any lectures or any materials.
Everything itās from the internet
I will read again those guides that I already read, hopefully I will understand better.
So are you trying to learn Prolog on your own? For your own purposes? What materials are you currently using? For what purpose are you going to use Prolog once you have learned it well enough?
Have you seen: Useful Prolog references
There are a few excellent and free books listed. You really should learn from a book or site such as Learn Prolog Now! instead of making up your own problems to learn. But once you know the basics, I always suggest that real world problems will help you learn more than a book.
While the syntax is slightly different you might find this site of use.
It might be of help to you. I know when I was learning unification it would have helped me.
I am curious to know if someone learning Prolog on their own finds the site of use and what problems they have with the site. The site has a few warts and with some enhancements/changes it could be very effective for new users.
.I have an assignment, which can be solved easily with python
I took a challenge and try to do this in Prolog which Iām not familiar with at all.
two weeks ago I even didnāt know there is language that called Prolog
This is the reasons that my problems related to the way I was try to implement my solution.
All materials are from the internet and PDF I founds their.
Thank you for trying to help.
I look at the sites Eric gave me.
If it can be solved easily with Python, it should be easier to solve with SWI-Prolog. But a new language is never going to be easy. On the other hand, this is the only way to learn something new and interesting. Again, good luck!
I think youāre fighting with the bigger difference between Prolog, as a relational language, and procedural languages, of which Python is a representant. Predicates ākeep their stateā in arguments, that are like assign once variables. So, do_something should ākeep its stateā in a global, just to track the fact that check_somthing(A) has succeded once. But obviously, a global is (usually) a poor choice in real problems and (usually) in any language. Try to add an argument to do_something, maybe it will clarify your algorithm because it will force you to think more relationally to your problem.
I disagree slightly. I often use print because the debugger can be too verbose and also only shows the result at the entry/exit of a predicate. (But my favourite debugging tool in any language is print ā¦ I suppose Iām old-fashioned.)
@moraneus ā itās worth learning the debugger; itās quite simple (space-bar will single-step; s skips over a single predicate; r re-does the predicate). spy/1 can be used to start the debugger at a particular predicate (although I often add a call to trace/0 in my code because I want to start at a particular call to a predicate). A common debugging situation is when a predicate fails that you expect to succeed ā one quick way of debugging is to skip until you get an unexpected failure, then re-do the failed predicate and single-step (I wish this were possible in debuggers for conventional languages, such as gdb, where I usually have to restart the debug session to do this).
Also, I suggest starting the debugger with gtrace ā¦ its display is much more user-friendly than the traditional terminal-oriented output.
(I have other tips for debugging, but they require a bit more knowledge of Prolog than you have, so Iāll refrain for now.)
Maybe I missed it but one thing I really like about using gtrace/0 is that if you have a predicate that fails deeply down in a call chain but donāt want to have to spend the time to find it by single stepping every line, instead single step the code at the highest level until a predicate fails, then redo that step, step into the next level and repeat as much as needed. This way as you are stepping down into the code you are understanding the context of what is happening as you step down.
With DCGs sometimes these bugs are at times 15 levels or more deep but being able to understand the context while stepping in means that when I get to the root cause I donāt have to rack my brain trying to align a stack trace with pages of code. The line with the bug is there, I know all of the calls in the stack trace, and the bound values of the variables are present along with the variables that are unbound. It doesnāt get much better.
Meanwhile Iām trying to debug with my head, follow the steps of shorts programs, then I checked my self.
I use now Visual debuger as @EricGT recommended.
It seems pretty good training. @peter.ludemann Thank you for your Answer
Sorry, that is not a visual debugger, it is a Prolog Visualizer.
AFAIK it was not created to help debug Prolog code but to understand how Prolog code works.
In my view itās greatest benefit is that it shows you the before and after changes of a unification which is one of the primary concepts essential for learning Prolog and one of the hardest to understand. I have never seen it done before visually, interactively and stepable both forward and backward as was done with that app.
While I donāt have time to take make it better by giving the ability to do cuts and to accept proper Prolog queries (there they end with ?), it has done so much right it is worth promoting for new users.
Yeah, you are right. I admit I also use print quite often (across languagesā¦). Using a debugger efficiently is not easy. I still feel a bit guilty (ābut why donāt you learn to use the debugger, Boris?ā) so I guess I was projecting.
I suspect there are also situations when debugging masks the bug.