[m-users.] Why can't `det` be used where `multi` is expected.

[Philip White]

Quoting Julian Fondren (2019-08-05 01:46:30)
> On 2019-08-04 23:02, Philip White wrote:
> mds.m:022:   in argument 1 of call to predicate 
> `getopt.process_options'/4:
> mds.m:022:   mode error: variable `OptionOps' has instantiatedness
> mds.m:022:     unique(
> mds.m:022:       option_ops_multi(
> mds.m:022:         /* unique */ (pred(in, out) is semidet),
> mds.m:022:         /* unique */ (pred(in, out) is semidet),
> mds.m:022:         /* unique */ (pred(out, out) is det)
> mds.m:022:       )
> mds.m:022:     ),

Wow, the formatting really helps a lot; I'll make sure to reformat
errors in the future. Maybe I'm getting errors wrong, but for me,
mds.err has both the expected and actual instantiatedness one the same
one line (well, multiple lines due to line wrapping). Errors don't get
logged by default for me, so I've been passing the -E flag.

Is there a way to have errors get pretty-printed?

> You can make the warning go away by adding this pragma:
> 
>    :- pragma no_determinism_warning(option_default/2).
> 
> from 
> https://mercurylang.org/information/doc-latest/mercury_ref/No-determinism-warnings.html

Cool; that's good to know.

> One reason to leave it as 'multi' is that it's probably a law of
> the universe that CLI interfaces gain options over time. You've got
> stars, but what about different Unicode stars? What about different
> colors of star? What about an option to slowly rather than
> instantly draw the stars?
> 
> Frozen in time, it looks like an error for a multi predicate to be
> obviously deterministic. So you wouldn't want to frame code like
> that for display in a museum. People will ask questions. But code
> is more often in motion.

Leaving it `multi` makes sense; I don't have any qualms about that, and
like you said, it likely would be changed to multi in the future. Good
explanation.