atom_t
actually represents a blob (see
section 12.4.10).
Blobs are the super type of Prolog atoms, where atoms are blobs that
represent textual content. Textual content is also represented by Prolog
string (see section 5.2),
which makes the general notion of string in Prolog ambiguous.
The core idea behind blobs/atoms is to represent arbitrary content using
a
unique handle, such that comparing the handles is enough to
prove equivalence of the contents; i.e., given two different atom
handles we know they represent different texts. This uniqueness feature
allows the core engine to reason about atom equality and inequality
without considering their content. Blobs without the PL_BLOB_UNIQUE
feature are also tested for uniqueness without considering their
content. Each time an atom or a PL_BLOB_UNIQUE
blob is
created, it must be looked up in the atom table; if a blob without
PL_BLOB_UNIQUE
is created, no lookup is done.
Strings (section 5.2)
and blobs without the
PL_BLOB_UNIQUE
feature do not have this uniqueness
property - to test for equality, the contents of the strings or blobs
must be compared. For both atoms and strings, comparisons for ordering
(e.g., used by sort/2
or @</2) must use the contents; in the case of blobs, compare()
can be specified in the
PL_blob_t
structure to override the default bitwise
comparison.
Because atoms are often used to represent (parts of) arbitrary input, intermediate results, and output of data processed by Prolog, it is necessary that atoms be subject to garbage collection (see garbage_collect_atoms/0). The garbage collection makes atoms ideal handles for arbitrary data structures, which are generalized as blobs. Blobs provide safe access to many internal Prolog data structures such as streams, clause references, etc.
int64_t
is defined in the stdint.h
standard
header and provides platform-independent 64-bit integers. Portable code
accessing Prolog should use this type to exchange integer values. Please
note that
PL_get_long()
can return FALSE
on Prolog integers that cannot be
represented as a C long. Robust code should not assume any of the
integer fetching functions to succeed, even if the Prolog term
is known to be an integer.
As of SWI-Prolog 7.3.12, the arity of terms has changed from int
to size_t
. To deal with this transition, all affecting
functions have two versions, where the old name exchanges the arity as int
and a new function with name *_sz() exchanges the arity as
size_t
. Up to 8.1.28, the default was to use the old int
functions. As of 8.1.29/8.2.x, the default is to use size_t
and the old behaviour can be restored by defining PL_ARITY_AS_SIZE
to 0
(zero). This makes old code compatible, but the
following warning is printed when compiling:
#warning "Term arity has changed from int to size_t." #warning "Please update your code or use #define PL_ARITY_AS_SIZE 0."
To make the code compile silently again, change the types you use to
represent arity from int
to size_t
. Please be
aware that
size_t
is unsigned. At some point representing
arity as int
will be dropped completely.