A.37.2 Options as arguments or environment?

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.