[m-rev.] for review: diagnose errors involving invariant tvars

[Peter Wang]

On Wed, 29 Jul 2026 12:18:12 +0200 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> +%---------------------%
> +
> +:- func describe_coerce_fail_should_be_invariant_arg(tvarset, type_ctor, uint,
> +    invariant_reason, mer_type, mer_type) = list(format_piece).
> +
> +describe_coerce_fail_should_be_invariant_arg(_TVarSet, BaseTypeCtor, ArgNum,
> +        Reason, _FromType, _ToType) = Pieces :-
> +    % XXX Should we print _FromType and _ToType?
> +    % In the usual case where BaseTypeCtor has a low arity, they will be
> +    % obvious from the names of the coerce-from and coerce-to types.
> +    (
> +        Reason = ir_higher_order,
> +        Pieces = [words("The type parameter that these types are bound to"),
> +            words("occurs in a higher order type."),
> +            words("Normally, it would be ok for the input arguments"),
> +            words("of higher order types to be co-variant,"),

I forgot to check this earlier.

Consider: any code that will call a higher-order function with a 'dog'
argument, you can safely provide a function that takes any 'animal'.
So input arguments can be CONTRA-variant. The opposite is true of
output/return arguments.

I will update the code.

Peter