Indicating choice point during debug

Request For Comments
#1

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

#3

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

#4

See Swiprologgraphicaldebugger | Eric Zinda Blog

2 Likes
#5

@ericzinda – this is beautiful.

I wish something like this exists for the profiling window as well – to explain what each element actually is :slight_smile:

#7

Yes, that is what i noticed when I looked at Eric’s description … I apparently never knew what i am looking at.

#9

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

#12

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.

#14

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.