[m-rev.] deduplicating getopt modules

[Julien Fischer]

On Sat, 19 Sep 2020, Zoltan Somogyi wrote:

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

On small thing we could (and I eventually intended to) do is move
to using structured errors by default and then get rid of the "_se"
predicates in the interface.  That would at least reduce the size of
the interface.  (That would obviously need to happen over a number of
releases.)

>> 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 :-(

The overhead will certainly be present, the compiler isn't great at
specialising such "templatey" uses of type classes.   That said, I think
you'd have to work quite hard to notice it.

Julien.