[m-rev.] for review: better error messages for lambda exprs

[Julien Fischer]

Hi Zoltan,

On Thu, 5 May 2016, Zoltan Somogyi wrote:

> For review by anyone. If possible, I would like a review of the
> change to NEWS by more than one person.
>
> Like several of my diffs in the last few months, this one improves
> the error messages we generate for syntax errors, but restricts
> the set of legal Mercury programs. If anyone objects to the restrictions
> imposed by this diff, please speak up.

...

> Improve error messages for malformed lambda expressions ...
> 
> ... and for malformed uses of some other builtin constructs that can appear
> in a unification. Do this by insisting that terms whose top level(s) look like
> a certain construct, should be parsed as that construct, and return error
> messages if that parsing attempt fails.
> 
> I did this is in several commits to modules in the parse_tree.m package
> that translated terms to the parse tree, i.e. to goal_exprs. This diff
> does the same thing for the arguments of unification goal_exprs, which
> we translate directly from terms to HLDS.

...

> compiler/field_access.m:
>     Clarity the text of an error message.

s/Clarity/Clarify/

...

> tests/invalid/invalid_int.err_exp:
>     Expect the updated text of the error message for a too-big
>     integer constant.

The alternative expected output, tests/invalid/invalid_int.err_exp2, will also
require updating.

...

> diff --git a/NEWS b/NEWS
> index 9b9f8a5..dbdb166 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -3,6 +3,23 @@ NEWS since Mercury 14.01.x
>
>  Changes that may break compatibility:
> 
> +* When the Mercury compiler looks at code using Mercury keywords (such as
> +  "if", "then" and "else") and Mercury operators (such as the field access
> +  operator "^") but which cannot be parsed as the Mercury constructs that
> +  those Mercury keywords and operators are part of, it now generates a specific
> +  error message for each discrepancy. In the past, when it found such code,
> +  the compiler considered such code to construct terms and/or to call
> +  functions and predicates. Since the terms usually did not any declared type

      did not belong to any declared type

> +  and the called functions and predicates did not exist, this usually led
> +  to confusing error messages from the compiler.
> +
> +  The compiler's current approach generates considerably better diagnostics,

s/current/new/

> +  but it does mean that code that uses Mercury's keywords and/or operators
> +  in ways that are inconsistent with Mercury's own uses of those keywords
> +  and operators won't compile anymore. Such code will need to be changed,
> +  typically by changing the names of some function symbols, functions
> +  or predicates.
> +

...

> diff --git a/compiler/superhomogeneous.m b/compiler/superhomogeneous.m
> index 5fedce3..0a1dae5 100644
> --- a/compiler/superhomogeneous.m
> +++ b/compiler/superhomogeneous.m

...

>      else
> -        Purity = purity_pure,
> -        Term = Term0
> +        % XXX Should we advertise any_pred/any_func?

Yes, they're a publicly documented part of the language.

> +        Pieces = [words("Error: the clause head part of a lambda expression"),
> +            words("should have one of the following forms:"),
> +            quote("pred(<args>) is <determinism>"), nl,
> +            quote("any_pred(<args>) is <determinism>"), nl,
> +            quote("func(<args>) = <retarg> is <determinism>"), nl,
> +            quote("any_func(<args>) = <retarg> is <determinism>"), nl,
> +            quote("func(<args>) = <retarg>"), nl,
> +            quote("any_func(<args>) = <retarg>"), suffix(","), nl,
> +            words("or one of those forms preceded by either"),
> +            quote("semipure"), words("or"), quote("impure"), suffix("."), nl],
> +        Msg = simple_msg(get_term_context(PFArgsDetTerm), [always(Pieces)]),
> +        Spec = error_spec(severity_error, phase_parse_tree_to_hlds, [Msg]),
> +        qual_info_set_found_syntax_error(yes, !QualInfo),
> +        MaybeLambdaHead = error1([Spec])
>      ).

The rest looks fine.

Julien.