[m-rev.] for review: better error messages for lambda exprs
jfischer at opturion.com
Fri May 6 09:48:51 AEST 2016
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.
> Clarity the text of an error message.
> 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
> 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,
> + 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
> - 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.
More information about the reviews