[m-rev.] for review: unify getopt and getopt_io

[Peter Wang]

On Fri, 09 Oct 2020 18:39:33 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> >> +    % All these predicates place all the non-option arguments in
> >> +    % 'NonOptionArgs', and the predicates that have an `OptionArgs' argument
> >> +    % place the option arguments there. (While some callers will want
> >> +    % the arguments contain the options, other callers will not, considering
> >> +    % that the only information they want from them is that contained in
> >> +    % the option table.)
> > 
> > I think we should deprecate
> > 
> >     process_options(OptionOps, Args, NonOptionArgs, Result)
> > 
> > and don't introduce
> > 
> >     process_options_io(OptionOps, Args, NonOptionArgs, Result, !IO)
> 
> The predicate now named process_options_io already existed before this diff,
> as getopt_io.process_options. The predicate now named process_options
> was its analogue in the getopt module.

Code that was calling getopt_io.process_options will need to be updated
to call process_options_io instead, in which case it can be updated to
call the variant that returns OptionArgs as well. It's also quite
possible that the only user of getopt_io is the compiler itself.

> These two predicates are cheap (their definitions consist of just one call each)
> and represent a common use case, so I don't see any reason to deprecate them.

The reason I suggested it was to further reduce the number of exported
predicates.

Peter