[m-rev.] deduplicating getopt modules

[Peter Wang]

On Sat, 19 Sep 2020 11:05:27 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 2020-09-19 10:50 GMT+10:00 "Peter Wang" <novalazy at gmail.com>:
> > Perhaps we should deprecate the getopt module and parameterise getopt_io
> > predicates by a typeclass. We would provide two typeclass instances,
> > one which can open and read files for file_special, and another which
> > does no I/O (so a file_special option will produce a runtime error).
> 
> Would the process_options predicate take an I/O pair of arguments, or not?
> 
> If it does, then we don't need a type class; the user can simply pass a flag
> that says whether file_specials should or should not be honored.
> 

That would be another option. It does require callers to pass in the I/O
state even if they don't need it, which is likely most users outside of
the compiler. Obviously, in practice, the I/O state is probably readily
available.

> Or are you proposing that process_options take a pair of arguments
> of type T, which *may* be I/O states at some call sites but not others, and that
> the type class constraint be on T? 

Something like:

    :- typeclass file_special_handler(T, S) <= (S -> T) where [ ... ].

    :- instance file_special_handler(io.input_stream, io.state).

    :- type no_file_special_handle.
    :- type no_file_special.
    :- instance file_special_handler(no_file_special_handle, no_file_special).

    :- pred process_options(option_ops(OptionType)::in(option_ops),
	list(string)::in, list(string)::out,
	maybe_option_table(OptionType)::out, S::di, S::uo) is det
	<= file_handler(S, T).

> If so, I would consider such an interface
> to be unnecessarily complex from a user's point of view. For example,
> the Haskell reddit is full of comments from people new to Haskell who
> wonder why they are getting error messages about unsatisfied
> type class constraints when they e.g. add together two values of
> incompatible types.

I think the getopt interface is already too complex for a new user :(

We could leave the typeclass as an implementation detail.
The single getopt/getopt_io module would expose two versions of each
process_options predicate, one that takes the I/O state and one that
doesn't. The only problem is there are a lot of overloads already.

Peter