Did you know ... Search Documentation:
Predicate is_list/1
Availability:built-in
is_list(+Term)
True if Term is bound to the empty list ([]) or a compound term with name‘[|]’137The traditional list functor name is the dot (’.’). This is still the case of the command line option --traditional is given. See also section 5.1. and arity 2 and the second argument is a list.138In versions before 5.0.1, is_list/1 just checked for [] or [_|_] and proper_list/1 had the role of the current is_list/1. The current definition conforms to the de facto standard. Assuming proper coding standards, there should only be very few cases where a quick-and-dirty is_list/1 is a good choice. Richard O'Keefe pointed at this issue. This predicate acts as if defined by the definition below on acyclic terms. The implementation safely fails if Term represents a cyclic list. 
is_list(X) :-
        var(X), !,
        fail.
is_list([]).
is_list([_|T]) :-
        is_list(T).

Examples

Convert a string of 0s and 1s to an integer

Convert a string of 0s and 1s to an integer

This shows how to convert almost any "string" of 0s and 1s to an integer.

It takes advantage of the built-in term reading, thus avoiding an explicit loop and arithmetic.

binary_string_to_int(Str, Int) :-
    (   ( string(Str) ; atom(Str) )
    ->  atomics_to_string(["0b", Str], Literal)
    ;   is_list(Str)
    ->  atomics_to_string(["0b"|Str], Literal)
    ;   type_error(string_type, Str)
    ),
    catch(term_string(Int, Literal, []),
          error(syntax_error(_), _),
          type_error(string_of_0s_and_1s, Str)).
?- binary_string_to_int('101', X).
X = 5.

?- binary_string_to_int([0, 0, 1, 0, 1], X).
X = 5.

?- binary_string_to_int(["1", "1", "0"], X).
X = 6.
What is wrong with intersection/3 and friends?

What is wrong with intersection/3 and friends?

The library(lists) contains a number of old predicates for manipulating sets represented as unordered lists, notably intersection/3, union/3, subset/2 and subtract/3. These predicates all use memberchk/2 to find equivalent elements. As a result these are not logical while unification can easily lead to dubious results. Operating on unordered sets these predicates typically have complexity |Set1|*|Set2|.

When using these predicates

  • Make sure to respect the mode, i.e., make sure the input lists are proper lists. See is_list/1.
  • Make sure elements are sufficiently instantiated such that their equality can safely be checked using unification. See ?=/2.
  • Make sure the inputs are indeed sets, i.e., the lists contain no duplicates. In this case, a list is considered to have a duplicate if two members of the list can unify.

Intended behavior

?- intersection([a,b,c], [b,e], X).
X = [b].
?- union([a,b,c], [b,e], X).
X = [a, c, b, e].
?- subset([a,b,c], [b,e]).
false.
?- subset([b], [b,e]).
true.
?- subtract([a,b,c], [b,e], X).
X = [a, c].

Dubious behavior

?- intersection([a,b,c], [b,E], X).
E = a,
X = [a, b].
?- subtract([a,b,c], [b,E], X).
E = a,
X = [c].

Insufficient instantiation also leads to problems

?- subtract([a,b,c], X, [c]).
false.

Note that duplicates in the input may result in duplicates in the output (example by Boris).

?- intersection([a,b,a], [b,a,b], I).
I = [a, b, a].
deprecated
- New code should use library(ordsets) instead.
Tags are associated to your profile if you are logged in|Report abuse
Tags:
  • doc-needs-help
LogicalCaptain said (2020-07-29T05:10:08):0 upvotes 0 0 downvotes
Picture of user LogicalCaptain.

The mode indicator seems wrong

The mode indicator + in is_list(+Term) says that Term should not be an unbound variable but some term following a minimal specification. But is_list/1 survives that in any case.

It would be better to have

is_list(@Term)

Argument will not be further instantiated than it is at call-time. Typically used for type tests.

That's exactly what is needed.

Some simple unit tests for this predicate

test_is_list.pl

Checking whether we have an open list

For list terminology, see the glossary

An open list has a "empty cell" at the last position of the list backbone

List1    = [1,2,3|[]]   % a "proper" (or "closed") list
List2    = [1,2,3]      % exactly the same as List1
OpenList = [1,2,3|_]    % open list: an unbound (even an anonymous) variable at Fin
OpenList = [1,2,3|Fin]  % open list with an unbound non-anonymous variable at Fin
OpenList = _            % limiting case: an open list with any listcell. a bit dubious

is_list/1 says no in those cases:

?- is_list(_).
false.

?- is_list([1,2,3|_]).
false.

Actually, the mode indicator + in is_list(+Term) says that Term should not be an unbound variable but some term following a minimal specification. But is_list/1 survives that in any case.

  • proper/closed list on the left
  • open list on the right
List ------->[|]                  [|]<-------------- OpenList
            /   \                /   \
           1    [|]             1    [|]
               /   \                /   \
              2    [|]             2    [|]
                  /   \                /   \
                 3     []             3   ~empty cell~ <--- Fin

How about a new is_list/2 then?

There is a Big Problem with Prolog inherent in untyped unbound variables. They could become anything. But: at the moment we check what they are, we just don't know whether we are supposed to succeed or fail.

is_list(_)

fails - but that's a statement about THE STATE OF THE COMPUTATION, not about the anonymous variable _. It is completely non-logical.

If an X could be "typed as a list" and is_list(X) failed with that typed X one could at least have a logical interpretation... `X is not now, and can never be, a list`.

Okay. So, how about a new is_list/2 then?

One that works like this:

It always succeeds with an unbound What but reifies the truth value into What so you can perform an acceptance/verification

is_list(+Term,-What)

with the following truth table:

% ---
% is_list(@Term,?What)
% ---
%
%
%                         +----------------------------------------------+
%                         |              accepted as What                |
%             +-----------+--------+---+----+-----+------+-------+-------+
%             | generated | true   |var|open|false|oclist|voclist|canlist|
%             | as What   | closed |   |    |     |      |       |       |
%             |           | proper |   |    |     |      |       |       |
%   +---------+-----------+--------+---+----+-----+------+-------+-------+
%   | []      | true      |  x     ,   ,    ,     ,  x   ,  x    ,       |
%   | [a,b,c] | true      |  x     ,   ,    ,     ,  x   ,  x    ,       |
%   | _       | var       |        , x ,    ,     ,      ,  x    ,  x    |
%   | [a,b|_] | open      |        ,   , x  ,     ,  x   ,  x    ,  x    |
%   | [a,b|x] | false     |        ,   ,    ,  x  ,      ,       ,       |
%   | foo     | false     |        ,   ,    ,  x  ,      ,       ,       |
%   +---------+-----------+----------------------------------------------+
  • "oclist" stands for "open or proper list (but not unbound variable)"
  • "voclist" stands for "open or proper list or unbound variable"
  • "canlist" stands for "not currently a proper list but can become one as it's an open list or an unbound variable"
  • when accepting, one can use closedor proper instead of true

Example:

?-
is_list([a,b,c],W).
W = true.

Term designates a closed/proper list. This is a strong logical statement: Term is a list now and this will stay so in the future.

?-
is_list([a,b|_],W).
W = open.

?- is_list(_,W).
W = var.

?- is_list(_,open).
false.  % actual failure

Term designates an open list with at least one listcell, i.e. is not an unbound variable. This is a statement about the state of the computation: Term is (the start of an) open list now but this may change in the future: the structure may become a closed list, stay an open list, or become a non-list. We really don't know.

?- is_list(_,W).
W = var.

Term is an unbound variable and we REALLY DON'T KNOW ANYTHING ELSE. This is a statement about the state of the computation: Term may become a closed list, a closed list with at least one listcell, may stay unbound or become something else. It may even be an empty open list "in the mind of the programmer" now (being an unbound variable), we don't have insight into that.

?- is_list(foo,W).
W = false.

Again, a strong logical statement: Term is not a proper list, not an open list of at least one listcell, not an unbound variable. It is "something else" with information content. So we can say "false" (but not fail).

And so: source code