[m-rev.] for review: Document how tuple types work in subtypes/coerce.

[Julien Fischer]

On Tue, 9 Jul 2024 at 14:34, Peter Wang <novalazy at gmail.com> wrote:
>
> doc/reference_manual.texi:
>     Include tuple types in the discussion of how subtype constructor
>     arguments may vary.
>
>     Include tuple types in the discussion of type-correctness of
>     coerce.
>
> diff --git a/doc/reference_manual.texi b/doc/reference_manual.texi
> index e382fea4d..53ea1dca9 100644
> --- a/doc/reference_manual.texi
> +++ b/doc/reference_manual.texi
> @@ -3357,8 +3357,9 @@ It may change the types of some of the arguments of some of the constructors,
>
>  Formally, this means that
>  if the supertype @samp{t} has a constructor @samp{f(T1, ..., Tn)},
> -and the subtype @samp{s =< t} has a constructor @samp{f(S1, ..., Sn)}.
> -then for each @var{Si}, the condition @samp{Si =< Ti} must hold.
> +and the subtype @samp{s =< t} has a constructor @samp{f(S1, ..., Sn)},
> +then for each @var{Si}, the condition @samp{Si =< Ti} must hold,
> +where @samp{=<} is the subtype relation below.
>  @end itemize
>
>  This is an example of the first kind of difference:
> @@ -3415,24 +3416,17 @@ that does not occur in @var{supertype}.
>  (In the following discussion,
>  we assume that all equivalence types have been expanded out.)
>
> -Mercury considers it possible
> -for a type @samp{S} to be a subtype of type @samp{T}, where @samp{S != T},
> -in two cases:
> -where @samp{S} and @samp{T} are both discriminated union type,
> -and where they are both higher order types.
> -In every other case,
> - at samp{S} is a subtype of @samp{T}, denoted @samp{S =< T},
> -if and only if @samp{S} and @samp{T} are syntactically identical,
> -i.e.@ @samp{S = T}.
> -
> -A discriminated union type @samp{S}
> -can be a subtype of another discriminated union type @samp{T}
> -in two distinct ways:
> +The subtype relation @samp{S =< T} has four cases to consider:
> +when @samp{S} and @samp{T} are both discriminated union types,
> +when they are both tuple types,
> +when they are both higher order types,

s/higher order/higher-order/

> +and all other types.

I suggest listing those cases using @itemize.

That looks fine otherwise.

Julien.