[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