[m-rev.] deduplicating getopt modules

[Zoltan Somogyi]

2020-09-19 12:46 GMT+10:00 "Peter Wang" <novalazy at gmail.com>:
>> 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).

I don't understand what the T argument of the typeclass is intended to be for.
The only operation the typeclass needs is "given a filename, return either
a string that is the contents of the file it names, or an error description",
which does not need any type beyond the I/O state.

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

Agreed, unfortunately.

> 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.

I see now what you are proposing: I think it can be made to work.
The overloads cause some complications, but not too much. They also
impose overhead, but that shouldn't matter. Very few programs process
their options more than four times, though mmc does :-(

Once you tell me what T is supposed to be for, I will look into this.
I just wish you made your suggestion yesterday :-)

Zoltan.