[m-rev.] for review: structured types in error messages

[Peter Wang]

On Mon, 21 Feb 2022 14:47:38 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 2022-02-21 11:59 GMT+11:00 "Peter Wang" <novalazy at gmail.com>:
> >> +            ArgPiecesList = [ReturnValuePieces],
> >> +            PorFArgBlockPieces = [fixed("func"), fixed("=")] ++
> >>                  FuncResultPrefixPieces ++ ReturnValuePieces ++
> >>                  FuncResultSuffixPieces
> > 
> > "(func)" instead of "func".
> 
> Function declarations without arguments do not need
> parentheses, as shown by e.g.
> 
> :- func max_one_line_type_length = int.
> 
> Function types without arguments do need parentheses
> when inside bigger types.
> 
> Therefore I see three options:
> 
> - Always add parentheses, which is misleading
>   if the function type is the outermost type.
> 
> - Never add parentheses, which is (readable, but)
>   misleading about the need for parentheses
>   if the function type is not the outermost type.
> 
> - Pass along a flag that says whether the type is
>   the outermost or not, and add parentheses
>   only if it is not.
> 
> I would prefer the third. Do you object?

I don't understand the relevance of function declarations here.
The type of max_one_line_type_length would have to be written
in a Mercury source file as:

    (func) = int

e.g.

    :- func max_one_line_type_length `with_type` ((func) = int).

I think error messages should (as far as possible) print types
in the same way they would be written in Mercury code.

However, I do see that the current compiler behaves as in your change:

    t.m:027:   Argument 1 (X) has type `func = int',
    t.m:027:   expected type was `int'.

Peter