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

Peter Wang novalazy at gmail.com
Mon Feb 21 17:05:00 AEDT 2022


On Mon, 21 Feb 2022 15:40:45 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 2022-02-21 15:34 GMT+11:00 "Peter Wang" <novalazy at gmail.com>:
> > 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).
> 
> Agreed, but that is what I meant by ((func) = int) being
> inside another type, which in this case is the whole line.
>

Function declarations appear at the top level of a Mercury source file,
but function declarations are not in of themselves "types".

> > I think error messages should (as far as possible) print types
> > in the same way they would be written in Mercury code.
> 
> Agreed; the question is: the same way they would be written
> in Mercury code *where*? Inside another type, or at the top level?
> You are arguing for the former, I am for the latter (for when the type
> is actually at the top level).

Types never occur at the top level of a Mercury source file, though.

Regardless, the Mercury parser would not accept (func = int) in any
context. That's why I'm arguing against it. Correct me if I'm wrong.

Peter


More information about the reviews mailing list