[m-rev.] for post-commit review: better diagnostic for missing higher order insts
Peter Wang
novalazy at gmail.com
Wed Jul 19 12:56:58 AEST 2023
On Wed, 19 Jul 2023 08:06:21 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> For review by everyone, if possible.
>
> Questions I would like feeback on:
>
> - Is the set of pieces of information it conveys right?
> Is it missing any important info?
> Does it include info it shouldn't?
>
> - Is the structure of the error message, the general approach
> it uses to convey the info it conveys, broadly right?
> If not, there is no point in discussing its details.
>
> - If the structure is right, are the details of its text right?
>
> - Can anyone propose an alternative that is better than
> the use of the _t and _i suffixes to distinguish the
> type and inst names?
>
> - The text would probably be improved if we added blank lines
> (it would break up the "wall" of text). If so, where should
> the blank lines go?
>
> - Should anything not currently quoted be quoted, or vice versa?
>
> Zoltan.
> diff --git a/tests/invalid/no_ho_inst.err_exp b/tests/invalid/no_ho_inst.err_exp
> index e69de29bb..7cba3af08 100644
> --- a/tests/invalid/no_ho_inst.err_exp
> +++ b/tests/invalid/no_ho_inst.err_exp
> @@ -0,0 +1,22 @@
> +no_ho_inst.m:044: In clause for `run_loop(in, in, out, di, uo)':
> +no_ho_inst.m:044: in argument 1 (i.e. the predicate term) of higher-order
> +no_ho_inst.m:044: predicate call:
> +no_ho_inst.m:044: mode error: context requires a predicate of arity 4, and
> +no_ho_inst.m:044: the type of AppHandler does match that expectation, but to
> +no_ho_inst.m:044: check the correctness of the call, the compiler also needs
> +no_ho_inst.m:044: to know the modes of the arguments and the determinism of
> +no_ho_inst.m:044: the predicate that AppHandler represents, and AppHandler's
> +no_ho_inst.m:044: inst does not contain that information.
My attempt:
In clause for `run_loop(in, in, out, di, uo)':
in argument 1 (i.e. the predicate term) of higher-order
predicate call:
mode error: the context requires a predicate of arity 4.
The type of AppHandler matches that expectation, but the inst of
AppHandler at this point is `ground', which lacks the higher-order
inst information required to make the call.
in which I think the improvements are:
- removes an interpretation where the reader might think the mode
error is due to a compiler limitation
- keeps the part which says that it's (probably) not a type error.
That seems like a good idea.
- prints out the problematic inst
- tells the user that "higher-order inst information" is required to
make a higher-order call, using those exact words so they can be
searched for in the reference manual
- removes the line about the "usual fix" which is vague
(although that might have been intended as a heading to the next part)
> +no_ho_inst.m:044: The usual fix for this error is to add this information.
> +no_ho_inst.m:044: Given a higher order type such as
> +no_ho_inst.m:044: :- type callback_t == (pred(world, world, io, io).
> +no_ho_inst.m:044: you would define a corresponding inst, such as
> +no_ho_inst.m:044: :- inst callback_i == (pred(in, out, di, uo) is det).
> +no_ho_inst.m:044: This inst specifies the modes of the arguments and the
> +no_ho_inst.m:044: determinism of a predicate. You can then tell the compiler
> +no_ho_inst.m:044: that a value of type callback_t has inst callback_i by
> +no_ho_inst.m:044: specifying either the mode `in(callback_i)' (when taking a
> +no_ho_inst.m:044: value of type callback_t as input) or the mode
> +no_ho_inst.m:044: `out(callback_i)' (when returning a value of type
> +no_ho_inst.m:044: callback_t as output).
> +For more information, recompile with `-E'.
I personally prefer not to see things like this in error messages.
Once you learn what's going on, it's tiring to be told the same long
piece of (non-specific) advice over and over.
A common situation where the error would arise is when someone tries to
take a higher-order term out of a container and tries to call it, then
the advice would not apply.
You could hide the advice behind the -E option.
Peter
More information about the reviews
mailing list