# Indicating choice point during debug **URL:** \ **Category:** Request For Comments\ **Tags:** discussion\ **Created:** [May 5, 2021, 9:26pm UTC](https://swi-prolog.discourse.group/t/indicating-choice-point-during-debug/3916 "2021-05-05T21:26:42Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [May 5, 2021, 9:26pm UTC](https://swi-prolog.discourse.group/t/indicating-choice-point-during-debug/3916/1 "2021-05-05T21:26:43Z")
Hello, While stepping through code with the visual debugger I noticed that upon calls of goals, I can’t tell whether upon return from a call, a choice point has been created or not. Given the importance of designing the code to eliminate unnecessary choice points, it would be great if upon return from a goal, the debugger could indicate whether a choice point has been created. What if there exist a choice point pane along side the call stack pane that shows a trail of predicates for which a choice point exist. I think this could be a great help in understanding whether cuts need to be included in the called predicate or whether at the call site – or whether other means of choice point “handling” / elimination need to be applied. Dan ---
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [May 5, 2021, 9:56pm UTC](https://swi-prolog.discourse.group/t/indicating-choice-point-during-debug/3916/3 "2021-05-05T21:56:36Z")
Thanks. That’s great. It looks like the visual debugger, which i am using all the time, doesn’t seem to offer an A for Alternative … to bad … But, i think some visual indicator that can be seen with a glance without the need to press A would be great. Dan ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [May 6, 2021, 6:27am UTC](https://swi-prolog.discourse.group/t/indicating-choice-point-during-debug/3916/4 "2021-05-06T06:27:37Z")
See [Swiprologgraphicaldebugger | Eric Zinda Blog](https://blog.inductorsoftware.com/blog/SWIPrologGraphicalDebugger) ---
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [May 6, 2021, 7:00am UTC](https://swi-prolog.discourse.group/t/indicating-choice-point-during-debug/3916/5 "2021-05-06T07:00:03Z")
@ericzinda – this is beautiful. I wish something like this exists for the profiling window as well – to explain what each element actually is 🙂 ---
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [May 6, 2021, 8:36am UTC](https://swi-prolog.discourse.group/t/indicating-choice-point-during-debug/3916/7 "2021-05-06T08:36:00Z")
Yes, that is what i noticed when I looked at Eric’s description … I apparently never knew what i am looking at. ---
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [May 6, 2021, 8:52am UTC](https://swi-prolog.discourse.group/t/indicating-choice-point-during-debug/3916/9 "2021-05-06T08:52:21Z")
I have been reading up on Rust lately, and one additional selling point – beside memory safety – is that its a non GC language- like C++/C. It seems that a call stack is not necessarily a performance issue, its the GC that requires its own runtime, while also making consistency in performance less predictable … I guess a Prolog without GC is not possible … Dan ---
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [May 6, 2021, 9:22am UTC](https://swi-prolog.discourse.group/t/indicating-choice-point-during-debug/3916/12 "2021-05-06T09:22:01Z")
Yes, indeed, i noticed the problem of rust with cyclic structures or even bi-directional linked-lists. The way out of this is either unsafe code – which is essentially a fall back to C/C++ – which isn’t too bad – or to use indexed structures (e.g. vecs) instead. Not so happy about this, but i guess, this is the price they are willing to pay for compile time memory ownership checks. Apparently, most costly bugs are located there – so if you want a non-memory managed language + (compile time checks for) memory safety + some non-race condition benefits for multi-threaded code – that’s then the way to go these days. ---
**Author:** ![grossdan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/grossdan/32/23_2.png) [@grossdan](https://swi-prolog.discourse.group/u/grossdan)\ **Post date:** [May 6, 2021, 9:27am UTC](https://swi-prolog.discourse.group/t/indicating-choice-point-during-debug/3916/14 "2021-05-06T09:27:30Z")
> [@anon95304481](#): > > trail compaction problem For Rust vec there is also the problem of increasing vec space – which makes a copy – and which can eat into performance as well. Apparently, there are solutions for that – which i didn’t fully understand yet.