[m-rev.] deduplicating getopt modules

[Zoltan Somogyi]

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.

If it does not, then process_options can implement file_special options
only by conjuring I/O states out of thin air like trace goals do, which would
mean that process_options has no semantics I would call declarative.

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

Zoltan.