[m-rev.] for review: Parse and check coerce expressions.

[Julien Fischer]

Hi Peter,

On Wed, 10 Mar 2021, Peter Wang wrote:

> This change implements parsing, typechecking, and modechecking of
> "coerce" expressions from my subtypes proposal, i.e. coerce(Term).
> Backends currently will abort if asked to generate code for coercions,
> as subtypes do not yet share data representations with their base types,
> so most coercions would lead to crashes at runtime anyway.

...

> diff --git a/NEWS b/NEWS
> index bc556a8a8..f5919d859 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -17,6 +17,11 @@ Changes that may break compatibility
> 
> * We have reserved `=<`/2 as a type name.
> 
> +* A term with a top level functor `coerce/1` is now treated as a

s/top level/top-level/

> +  type conversion expression. To call a function named `coerce/1`,
> +  you can module qualify the name at the call site,
> +  or wrap parentheses around the name, e.g. `(coerce)(Arg)`.

...

> diff --git a/compiler/hlds_goal.m b/compiler/hlds_goal.m
> index b59e8773e..f98d79628 100644
> --- a/compiler/hlds_goal.m
> +++ b/compiler/hlds_goal.m
> @@ -700,7 +700,11 @@
>                 % A cast generic_call with two arguments, Input and Output,
>                 % assigns `Input' to `Output', performing a cast of this kind.
>                 cast_kind       :: cast_kind
> -            ).
> +            )
> +
> +    ;       coerce.
> +            % A coerce expression with two arguments, Input and Output,
> +            % assigns `Input' to `Output'.


Did you consider representing coerce expressions by adding a new alternative to
the cast_kind type and using the cast constructor?  (Most of the code seems to
treat them identically anyway.)

Also, it might be better to use a more specific name, such as 'subtype_coerce',
for the constructor.

The rest looks fine; I'll do a post-commit review of the reference manual changes
since they was a bit awkward to follow in diff form.

Julien.