:- vs. => and "spurious" choice point creation or not in SSU (=>)

Hello,

When I write code with => rather than :- as below, looking at the vm code via vm_list, i noticed that quite different code is generated, one making use of i_ssu_commit, and the other of i_cut …

I wonder does the SSU solution create choice points upon encountering the lists in the head of both clauses or not …

My overall objective is to write performant code when for most cases a findall only finds one; and few cases a list of two, and the findall result need to be subsequently processed.

Currently, a first call to to processing predicate with a [First | Rest] which most of the cases leads to a Rest == [] – which then leads to a recursive call of [].

Instead i hope to resolve the one in one call only.

thanks,

Dan

p_list([]) => true.

p_list([Element]) =>
	writeln(Element).
	
p_list([First | Rest]) =>
	p_list([First]),
	p_list(Rest).

?- p_list([a]).
a
true.


p_list([]).

p_list([Element]) :-
        !,
	writeln(Element).
	
p_list([First | Rest]) :-
	p_list([First]),
	p_list(Rest).

In situations like this, so called “data determinism”:

You always get spurious choice points in Prolog.

Example:

?- member(b,[a,b,c]).
true ;
false.

“data determinism” is when an essentially multi predicate is called with
some data so that it has a single solution. This is different from “structural
determinism” where for all data the predicate is always deterministic.

The current Protobuf implementation has like 2-3 locations of a DCG
predicates that leave a spurious choice point.

Its not so difficult to spot these locations.

The below example is not spurious:

“spurious” means no side effect and failure. But the above example has
side-effect and succeeds on backtracking:

?- p_list([a,b,c]).
a
b
c
true ;
c
Etc..

Its more an unwanted non-determinism and not a spurious choice point.

1 Like

thank you for clarifying