Anomaly in GNU Prolog `delete/3` predicate?

Question

I found an inconsistency in behavior in the GNU Prolog (version 1.4.2) delete/3 predicate:

| ?- delete([a,b,c], b, R).

R = [a,c]

yes
| ?- delete([(a,_), (b,_), (c,_)], (b,_), R).

R = [(a,_),(b,_),(c,_)]

yes
| ?- member( (b,_), [(a,_), (b,_), (c,_)] ).

true ? ;

no
| ?- select((b,_), [(a,_), (b,_), (c,_)], R).

R = [(a,_),(c,_)] ? ;

no
| ?-

All of the above results I expected, except for that of, delete([(a,_), (b,_), (c,_)], (b,_), R).. If you run the same set of queries in SWI Prolog, for example, the delete([(a,_), (b,_), (c,_)], (b,_), R). yields, R = [(a,_), (c,_)] as I would expect.

My question is whether this is expected based upon some specific "interpretation" of the delete/3 predicate, or is it perhaps a bug in GNU Prolog?

Answer 1

The name delete is terribly non-descriptive. Does it mean deleting all equal elements or all matching elements? If the later, does the unification between the element we're deleting and an element of the list carries when moving to the next list element or is undone?

From your trace above, in particular the second query, it seems that delete/3 is using equality instead of unification (as, as you know, each occurrence of an anonymous variable is a different variable). The documentation confirms it:

http://www.gprolog.org/manual/gprolog.html#sec213

There's really no bug as there's no consensus on a unique semantics for a delete/3predicate. At most, there's a consensus that's a bad name for a library predicate. Just a predicate name that should be avoided in any Prolog library. That said, compatibility with old code often results in its presence.