A db-spec has the form of a `speclist`:

`speclist`- =
`[`

`spec1`, ...,`specM``]`

`spec`- =
`functor``(`

`argspec1`, ...,`argspecN``)`

`argspec`- =
`+`

|`-`

A spec `F``(`

`argspec1`, ..., `argspecN``)`

is
*applicable* to any nonvar term with principal functor
`F`/`N`.

When storing a term `T` we generate a hash code for every
applicable spec in the db-spec, and a reference to `T` is stored
with each of them. (More precisely with each element of the set of
generated hash codes). If `T` contains nonvar elements on each
`+`

position in the spec, then the hash code depends on each of
these elements. If `T` does contain some variables on
`+`

position, then the hash code depends only on the functor
of `T`.

When fetching a term `Q` we look for an applicable spec for
which there are no variables in `Q` on positions maked
`+`

. If no applicable spec can be found a domain error is raised.
If no spec can be found where on each `+`

position a nonvar
term occurs in `Q` an instantiation error is raised.
Otherwise, we choose the the spec with the most `+`

postitions in
it breaking ties by choosing the leftmost one.

The terms that contain nonvar terms on every `+`

postition will be looked up using indexing based on the principal
functor of the term and the principal functor of
terms on `+`

postitions. The other (more general)
terms will be looked up using an indexing based on the principal
functor of the term only.

As can be seen, storing and fetching terms with variables on
`+`

positions are not vigorously supported operations.