[m-rev.] for post-commit review: add color in mode_errors.m

[Julien Fischer]

On Thu, 2 May 2024, Zoltan Somogyi wrote:

> On 2024-05-01 23:43 +10:00 AEST, "Julien Fischer" <jfischer at opturion.com> wrote:
>>> +bug117.m:028:   Final instantiatedness of `X' was `ground',
>>> +bug117.m:028:   expected final instantiatedness was 
>>> +bug117.m:028:     named inst list.non_empty_list
>>> +bug117.m:028:     which expands to
>>> +bug117.m:028:       bound(
>>> +bug117.m:028:         '[|]'(ground, ground)
>>> +bug117.m:028:       ).
>>
>> I wonder if "named inst" and "which expands to" should not be colored,
>> so as the actual insts stand out.  (OTOH, given the size some of those
>> inst expressions grow to the in the other messages I can see why you
>> did it this way.)
>
> The thing is, text of the form "named inst ..., which expands to ..." can occur
> not just at the top level, but in the middle of other insts as well.
> Treating the two cases differently is possible, but it would be a lot of work, and
> I don't think it is worthwhile.

Hence, my comment in parentheses.

...

>>> diff --git a/tests/invalid/no_ho_inst.err_exp b/tests/invalid/no_ho_inst.err_exp
>>> index cc44364a4..b615b813e 100644
>>> --- a/tests/invalid/no_ho_inst.err_exp
>>> +++ b/tests/invalid/no_ho_inst.err_exp
>>> @@ -1,14 +1,14 @@
>>>  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. The
>>> -no_ho_inst.m:044:   type of AppHandler does match that expectation. However, 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. The insts of
>>> -no_ho_inst.m:044:   higher order values should contain this information, but
>>> -no_ho_inst.m:044:   AppHandler's inst, which is `ground' at this point, does
>>> -no_ho_inst.m:044:   not.
>>> +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.
>>> +no_ho_inst.m:044:   However, to check the correctness of the call, the compiler
>>> +no_ho_inst.m:044:   also needs to know the modes of the arguments and the
>>> +no_ho_inst.m:044:   determinism of the predicate that AppHandler represents.
>>> +no_ho_inst.m:044:   The insts of higher order values should contain this
>>> +no_ho_inst.m:044:   information, but AppHandler's inst, which is `ground' at
>>> +no_ho_inst.m:044:   this point, does not.
>>>  no_ho_inst.m:044:
>>>  no_ho_inst.m:044:   The fix for this error is to add this information. For
>>>  no_ho_inst.m:044:   example, given a higher order type such as
>>
>> Unrelated: presumably AppHandler should quoted in that one since it's a program variable.
>
> As a variable, it must start with an upper case letter. I think that is sufficient
> to make it clear that it is variable, especially when I color its first occurrence
> with cyan. Do you disagree?

We quote {program,type,inst} variables in *many* other error message:
why do we not do it here?

Julien.