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.
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 …
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.
