We distinguish two views on options. One is to see them as additional
parameters that require strict existence, type and domain-checking and
the other is to consider them‘locally scoped environment variables’.
Most systems adopt the first option. SWI-Prolog adopts the second: it
silently ignores options that are not supported but does type and domain
checking of option-values. The‘environment’view is commonly
used in applications to create predicates supporting more options using
the skeleton below. This way of programming requires that pred1
and
pred2 do not interpret the same option differently. In cases
where this is not true, the options must be distributed by some_pred.
We have been using this programming style for many years and in practice
it turns out that the need for active distribution of options is rare.
I.e., options either have distinct names or multiple predicates
implement the same option but this has the desired effect. An example of
the latter is the encoding option, which typically needs to
be applied consistently.
some_pred(..., Options) :-
pred1(..., Options),
pred2(..., Options).
As stated before, options provide a readable alternative to
high-arity predicates and offer a robust mechanism to evolve the API,
but at the cost of some runtime overhead and weaker consistency
checking, both at compiletime and runtime. From our experience, the‘environment’approach
is productive, but the consequence is that mistyped options are silently
ignored. The option infrastructure described in this section tries to
remedy these problems.
