% This LaTeX document was generated using the LaTeX backend of PlDoc,
% The SWI-Prolog documentation system



\section{library(optparse): command line parsing}

\label{sec:optparse}

\begin{tags}
    \tag{author}
Marcus Uneson
    \tag{version}
0.20 (2011-04-27)
    \tag{To be done}
: validation? e.g, numbers; file path existence; one-out-of-a-set-of-atoms
\end{tags}

This module helps in building a command-line interface to an
application. In particular, it provides functions that take an option
specification and a list of atoms, probably given to the program on the
command line, and return a parsed representation (a list of the
customary Key(Val) by default; or optionally, a list of Func(Key, Val)
terms in the style of \predref{current_prolog_flag}{2}). It can also synthesize a
simple help text from the options specification.

The terminology in the following is partly borrowed from python, see
\url{http://docs.python.org/library/optparse.html#terminology} . Very briefly,
\textit{arguments} is what you provide on the command line and for many prologs
show up as a list of atoms \verb$Args$ in \verb$current_prolog_flag(argv, Args)$. For a typical prolog incantation, they can be divided into

\begin{itemize}
    \item \textit{runtime arguments}, which controls the prolog runtime;
conventionally, they are ended by '--';
    \item \textit{options}, which are key-value pairs (with a boolean value
possibly implicit) intended to control your program in one way
or another; and
    \item \textit{positional arguments}, which is what remains after
all runtime arguments and options have been removed (with
implicit arguments -- true/false for booleans -- filled in).
\end{itemize}

Positional arguments are in particular used for mandatory arguments
without which your program won't work and for which there are no
sensible defaults (e.g,, input file names). Options, by contrast, offer
flexibility by letting you change a default setting. Options are
optional not only by etymology: this library has no notion of mandatory
or required options (see the python docs for other rationales than
laziness).

The command-line arguments enter your program as a list of atoms, but
the programs perhaps expects booleans, integers, floats or even prolog
terms. You tell the parser so by providing an \textit{options specification}.
This is just a list of individual option specifications. One of those,
in turn, is a list of ground prolog terms in the customary Name(Value)
format. The following terms are recognized (any others raise error).

\begin{description}
    \termitem{opt}{Key}
\arg{Key} is what the option later will be accessed by, just like for
\verb$current_prolog_flag(Key, Value)$. This term is mandatory (an error is
thrown if missing).
    \termitem{shortflags}{ListOfFlags}
\arg{ListOfFlags} denotes any single-dashed, single letter args specifying the
current option (\verb$-s , -K$, etc). Uppercase letters must be quoted.
Usually \arg{ListOfFlags} will be a singleton list, but sometimes aliased flags
may be convenient.
    \termitem{longflags}{ListOfFlags}
\arg{ListOfFlags} denotes any double-dashed arguments specifying
the current option (\verb$--verbose, --no-debug$, etc). They are
basically a more readable alternative to short flags, except
\end{description}

\begin{enumerate}
    \item long flags can be specified as \verb$--flag value$ or
\verb$--flag=value$ (but not as \verb$--flagvalue$); short flags as
\verb$-f val$ or \verb$-fval$ (but not \verb$-f=val$)
    \item boolean long flags can be specified as \verb$--bool-flag$
or \verb$--bool-flag=true$ or \verb$--bool-flag true$; and they can be
negated as \verb$--no-bool-flag$ or \verb$--bool-flag=false$ or
\verb$--bool-flag false$.

Except that shortflags must be single characters, the
distinction between long and short is in calling convention, not
in namespaces. Thus, if you have \verb$shortflags([v])$, you can use it
as \verb$-v2$ or \verb$-v 2$ or \verb$--v=2$ or \verb$--v 2$ (but not
\verb$-v=2$ or \verb$--v2$).

Shortflags and longflags both default to \verb$[]$. It can be useful to
have flagless options -- see example below.
\end{enumerate}

\begin{description}
    \termitem{meta}{Meta}
\arg{Meta} is optional and only relevant for the synthesized usage message
and is the name (an atom) of the metasyntactic variable (possibly)
appearing in it together with type and default value (e.g,
\verb$x:integer=3$, \verb$interest:float=0.11$). It may be useful to
have named variables (\verb$x$, \verb$interest$) in case you wish to
mention them again in the help text. If not given the \verb$Meta:$
part is suppressed -- see example below.
    \termitem{type}{Type}
\arg{Type} is one of \verb$boolean, atom, integer, float, term$.
The corresponding argument will be parsed appropriately. This
term is optional; if not given, defaults to \verb$term$.
    \termitem{default}{Default}
\arg{Default} value. This term is optional; if not given, or if given the
special value '_', an uninstantiated variable is created (and any
type declaration is ignored).
    \termitem{help}{Help}
\arg{Help} is (usually) an atom of text describing the option in the
help text. This term is optional (but obviously strongly recommended
for all options which have flags).

Long lines are subject to basic word wrapping -- split on white
space, reindent, rejoin. However, you can get more control by
supplying the line breaking yourself: rather than a single line of
text, you can provide a list of lines (as atoms). If you do, they
will be joined with the appropriate indent but otherwise left
untouched (see the option \const{mode} in the example below).
\end{description}

Absence of mandatory option specs or the presence of more than one for a
particular option throws an error, as do unknown or incompatible types.

As a concrete example from a fictive application, suppose we want the
following options to be read from the command line (long \verb$flag(s)$, short
\verb$flag(s)$, meta:type=default, help)

\begin{code}
--mode                  -m     atom=SCAN       data gathering mode,
                                               one of
                                                SCAN: do this
                                                READ: do that
                                                MAKE: make numbers
                                                WAIT: do nothing
--rebuild-cache         -r     boolean=true    rebuild cache in
                                               each iteration
--heisenberg-threshold  -t,-h  float=0.1       heisenberg threshold
--depths, --iters       -i,-d  K:integer=3     stop after K
                                               iterations
--distances                    term=[1,2,3,5]  initial prolog term
--output-file           -o     FILE:atom=_     write output to FILE
--label                 -l     atom=REPORT     report label
--verbosity             -v     V:integer=2     verbosity level,
                                               1 <= V <= 3
\end{code}

We may also have some configuration parameters which we currently think
not needs to be controlled from the command line, say
\verb$path('/some/file/path')$.

This interface is described by the following options specification
(order between the specifications of a particular option is irrelevant).

\begin{code}
ExampleOptsSpec =
    [ [opt(mode    ), type(atom), default('SCAN'),
        shortflags([m]),   longflags(['mode'] ),
        help([ 'data gathering mode, one of'
             , '  SCAN: do this'
             , '  READ: do that'
             , '  MAKE: fabricate some numbers'
             , '  WAIT: don''t do anything'])]

    , [opt(cache), type(boolean), default(true),
        shortflags([r]),   longflags(['rebuild-cache']),
        help('rebuild cache in each iteration')]

    , [opt(threshold), type(float), default(0.1),
        shortflags([t,h]),  longflags(['heisenberg-threshold']),
        help('heisenberg threshold')]

    , [opt(depth), meta('K'), type(integer), default(3),
        shortflags([i,d]),longflags([depths,iters]),
        help('stop after K iterations')]

    , [opt(distances), default([1,2,3,5]),
        longflags([distances]),
        help('initial prolog term')]

    , [opt(outfile), meta('FILE'), type(atom),
        shortflags([o]),  longflags(['output-file']),
        help('write output to FILE')]

    , [opt(label), type(atom), default('REPORT'),
        shortflags([l]), longflags([label]),
        help('report label')]

    , [opt(verbose),  meta('V'), type(integer), default(2),
        shortflags([v]),  longflags([verbosity]),
        help('verbosity level, 1 <= V <= 3')]

    , [opt(path), default('/some/file/path/')]
    ].
\end{code}

The help text above was accessed by \verb$opt_help(ExamplesOptsSpec, HelpText)$. The options appear in the same order as in the OptsSpec.

Given \verb$ExampleOptsSpec$, a command line (somewhat syntactically
inconsistent, in order to demonstrate different calling conventions) may
look as follows

\begin{code}
ExampleArgs = [ '-d5'
              , '--heisenberg-threshold', '0.14'
              , '--distances=[1,1,2,3,5,8]'
              , '--iters', '7'
              , '-ooutput.txt'
              , '--rebuild-cache', 'true'
              , 'input.txt'
              , '--verbosity=2'
              ].
\end{code}

\verb$opt_parse(ExampleOptsSpec, ExampleArgs, Opts, PositionalArgs)$ would then
succeed with

\begin{code}
Opts =    [ mode('SCAN')
          , label('REPORT')
          , path('/some/file/path')
          , threshold(0.14)
          , distances([1,1,2,3,5,8])
          , depth(7)
          , outfile('output.txt')
          , cache(true)
          , verbose(2)
          ],
PositionalArgs = ['input.txt'].
\end{code}

Note that \verb$path('/some/file/path')$ showing up in Opts has a default value
(of the implicit type 'term'), but no corresponding flags in OptsSpec.
Thus it can't be set from the command line. The rest of your program
doesn't need to know that, of course. This provides an alternative to
the common practice of asserting such hard-coded parameters under a
single predicate (for instance \verb$setting(path, '/some/file/path')$), with
the advantage that you may seamlessly upgrade them to command-line
options, should you one day find this a good idea. Just add an
appropriate flag or two and a line of help text. Similarly, suppressing
an option in a cluttered interface amounts to commenting out the flags.

\predref{opt_parse}{5} allows more control through an additional argument list as
shown in the example below.

\begin{code}
?- opt_parse(ExampleOptsSpec, ExampleArgs,  Opts, PositionalArgs,
             [ output_functor(appl_config)
             ]).

Opts =    [ appl_config(verbose, 2),
          , appl_config(label, 'REPORT')
          ...
          ]
\end{code}

This representation may be preferable with the empty-flag configuration
parameter style above (perhaps with asserting \predref{appl_config}{2}).

\subsection{Notes and tips}

\label{sec:optparse-notes}

\begin{itemize}
    \item In the example we were mostly explicit about the types. Since the
default is \verb$term$, which subsumes \verb$integer, float, atom$, it
may be possible to get away cheaper (e.g., by only giving booleans).
However, it is recommended practice to always specify types:
parsing becomes more reliable and error messages will be easier to interpret.
    \item Note that \verb$-sbar$ is taken to mean \verb$-s bar$, not \verb$-s -b -a -r$,
that is, there is no clustering of flags.
    \item \verb$-s=foo$ is disallowed. The rationale is that although some
command-line parsers will silently interpret this as \verb$-s =foo$, this is very
seldom what you want. To have an option argument start with '=' (very
un-recommended), say so explicitly.
    \item The example specifies the option \verb$depth$ twice: once as
\verb$-d5$ and once as \verb$--iters 7$. The default when encountering duplicated
flags is to \verb$keeplast$ (this behaviour can be controlled, by ParseOption
duplicated_flags).
    \item The order of the options returned by the parsing functions is the same as
given on the command
line, with non-overridden defaults prepended and duplicates removed
as in previous item. You should not rely on this, however.
    \item Unknown flags (not appearing in OptsSpec) will throw errors. This
is usually a Good Thing. Sometimes, however, you may wish to pass
along flags to an external program (say, one called by \predref{shell}{2}), and
it means duplicated effort and a maintenance headache to have to
specify all possible flags for the external program explicitly (if
it even can be done). On the other hand, simply taking all unknown
flags as valid makes error checking much less efficient and
identification of positional arguments uncertain. A better solution
is to collect all arguments intended for passing along to an
indirectly called program as a single argument, probably as an atom
(if you don't need to inspect them first) or as a prolog term (if
you do).
\end{itemize}

\vspace{0.7cm}

\begin{description}
    \predicate[det]{opt_arguments}{3}{+OptsSpec, -Opts, -PositionalArgs}
Extract commandline options according to a specification.
Convenience predicate, assuming that command-line arguments can be
accessed by \predref{current_prolog_flag}{2} (as in swi-prolog). For other
access mechanisms and/or more control, get the args and pass them
as a list of atoms to \predref{opt_parse}{4} or \predref{opt_parse}{5} instead.

\arg{Opts} is a list of parsed options in the form Key(Value). Dashed
args not in \arg{OptsSpec} are not permitted and will raise error (see
tip on how to pass unknown flags in the module description).
\arg{PositionalArgs} are the remaining non-dashed args after each flag
has taken its argument (filling in \const{true} or \const{false} for booleans).
There are no restrictions on non-dashed arguments and they may go
anywhere (although it is good practice to put them last). Any
leading arguments for the runtime (up to and including '--') are
discarded.

    \predicate[det]{opt_parse}{4}{+OptsSpec, +ApplArgs, -Opts, -PositionalArgs}
Equivalent to \verb$opt_parse(OptsSpec, ApplArgs, Opts, PositionalArgs, [])$.

    \predicate[det]{opt_parse}{5}{+OptsSpec, +ApplArgs, -Opts, -PositionalArgs, +ParseOptions}
Parse the arguments Args (as list of atoms) according to \arg{OptsSpec}.
Any runtime arguments (typically terminated by '--') are assumed to
be removed already.

\arg{Opts} is a list of parsed options in the form Key(Value), or (with
the option \verb$functor(Func)$ given) in the form Func(Key, Value).
Dashed args not in \arg{OptsSpec} are not permitted and will raise error
(see tip on how to pass unknown flags in the module description).
\arg{PositionalArgs} are the remaining non-dashed args after each flag
has taken its argument (filling in \const{true} or \const{false} for booleans).
There are no restrictions on non-dashed arguments and they may go
anywhere (although it is good practice to put them last).
\arg{ParseOptions} are

\begin{description}
    \termitem{output_functor}{Func}
Set the functor \arg{Func} of the returned options \arg{Func}(Key,Value).
Default is the special value 'OPTION' (upper-case), which makes
the returned options have form Key(Value).
    \termitem{duplicated_flags}{Keep}
Controls how to handle options given more than once on the commad line.
\arg{Keep} is one of \verb$keepfirst, keeplast, keepall$ with the obvious meaning.
Default is \verb$keeplast$.
    \termitem{allow_empty_flag_spec}{Bool}
If true (default), a flag specification is not required (it is allowed
that both shortflags and longflags be either \Snil{} or absent).
Flagless options cannot be manipulated from the command line
and will not show up in the generated help. This is useful when you
have (also) general configuration parameters in
your \arg{OptsSpec}, especially if you think they one day might need to be
controlled externally. See example in the module overview.
\verb$allow_empty_flag_spec(false)$ gives the more customary behaviour of
raising error on empty flags.
\end{description}

    \predicate[det]{opt_help}{2}{+OptsSpec, -Help:atom}
True when \arg{Help} is a help string synthesized from \arg{OptsSpec}.

    \predicate[semidet,multifile]{parse_type}{3}{+Type, +Codes:list(code), -Result}
Hook to parse option text \arg{Codes} to an object of type \arg{Type}.
\end{description}

