From what I gather, it doesn’t behave like Erlang, simply because Erlang does not not have choice points – so any subgoal would not generate choice points either. Whereas, Picat => may be non-deterministic after all, despite the cut after the guard, while Erlang will always be determinstic.
You are saying that Head, Guard => (G->P;Q) is deterministic if P is semi-deterministic or deterministic.
But, that is exactly the reason why i felt that => is not Erlang equivalent.
Its only equivalent if you arrange the Body in Prolog to be deterministic – with whatever scheme you choose … it can be an if-the-else with deterministic subgoals – or it can be a body with determinstic subgoals – whichever …
Prolog is a generalization of the functional paradigm, which includes non-determinism.
Non-determinism and choice points is at the core of Prolog and is deeply ingrained in the Prolog execution engine. And even when no choice point is generated due to careful Prolog encoding of deterministic relations – the Prolog engine will have to check for that during runtime in order to decide to not create a choice point.
Hence, the benefit of non-determinism adds overhead – no matter what.
Currently, it seems that reducing some part of Prolog to a functional and deterministic island (which i thought => does) is not worth the cost of the added complexity in the VM execution engine – hence its not done.
I personally, would want one day to try out fork where I somehow manage to pause choice point creation and testing – for, say, a =!> operator – at least in a shallow or deep way – to see if it does indeed make a difference or not.
Despite the naming, the SWI-Prolog VM is based on a minimal VM described by Pereira [sic] and Byrd which is closely related to the `ZIP’ VM. The main difference is that this VM passes arguments over the stack rather than using registers.