An obvious approach to deal with options is to define the different
possible option values as a type and type the argument that processes
the option as list(<option_type>), as
illustrated below. Considering options as types fully covers the case
where we consider options as additional parameters.
:- type open_option ---> type(stream_type) |
alias(atom) | ... .
:- pred open(source_sink, open_mode, stream, list(open_option)).
There are three reasons for considering a different approach:
- There is no consensus about types in the Prolog world, neither about
what types should look like, nor whether or not they are desirable. It
is not likely that this debate will be resolved shortly.
- Considering options as types does not support the‘environment’view,
which we consider the most productive.
- Even when using types, we need reflective access to what options are
provided in order to be able to write compile or runtime conditional
code.
