[m-rev.] for review: Make subtypes share standard ordering with base type.

[Julien Fischer]

Hi Peter,

On Thu, 1 Apr 2021, Peter Wang wrote:

> doc/reference_manual.texi:
>    Define the standard ordering of a subtype to be the same as that of
>    its base type.
>
>    Suggest that subtype constructors should be declared in the same
>    order as in the supertype.
>
> compiler/add_type.m:
>    Warn if a subtype's constructors are declared in a different
>    relative order to the supertype.
>
> compiler/unify_proc.m
>    Generate unify/compare procs for subtypes that cast to the base type
>    then call the unify/compare proc for the base type. This was
>    previously done only for the high-level data representation.
>
> tests/hard_coded/Mmakefile:
> tests/hard_coded/subtype_order.exp:
> tests/hard_coded/subtype_order.m:
> tests/warnings/Mmakefile:
> tests/warnings/subtype_order.exp:
> tests/warnings/subtype_order.m:
>    Add test cases.

...

> diff --git a/doc/reference_manual.texi b/doc/reference_manual.texi
> index bf3717947..7c7497d7e 100644
> --- a/doc/reference_manual.texi
> +++ b/doc/reference_manual.texi
> @@ -2551,7 +2551,8 @@ Any universally quantified type variable that occurs in @var{body}
> must occur in @var{subtype}.
> 
> The constructor definitions must be a
> -subset of the constructors of the supertype.
> +subset of the constructors of the supertype;
> +they should appear in the same relative order as in the supertype definition.

I suggest changing that last bit to:

     we recommend they appear in the same relative order ...

> If the supertype @samp{t} has constructor @samp{f(T1, ..., Tn)} then
> a subtype @samp{s =< t} may have a constructor @samp{f(S1, ..., Sn)}.
> For each @var{Si}, it must be that @samp{Si =< Ti}.
> @@ -3055,7 +3056,7 @@ For tuple types, corresponding arguments are compared,
> with the first argument being the most significant,
> then the second, and so on.

That's fine otherwise.

Julien.