Can the type checker generate a more helpful error here?

[RieksJ]

I used Ampersand v3.5.1[development:28036cb] to compile

{-01-} CONTEXT BugX IN ENGLISH
{-02-}
{-03-} CLASSIFY Concern ISA Variable
{-04-}
{-05-} varValue :: Variable * VarValue [UNI]
{-06-} varTrace :: Variable * Assignment [UNI,INJ]
{-07-} asmValue :: Assignment * VarValue [UNI,TOT]
{-08-}
{-09-} RULE "one": (I[Variable]-I[Concern]);varValue |- varTrace;asmValue
{-10-} RULE "two": (I[Variable]-I[Concern]) |- varTrace;(I-asmValue;asmValue~)
{-11-}
{-12-} ENDCONTEXT

This resulted in the following output:

Error at symbol () in file BugX.adl at line 10 : 51
  Cannot disambiguate: I
  Please add a signature.
  You may have intended one of these:
  I[Concern]
  I[Variable]

Note that line 10:51 refers to the I in I-asmValue;asmValue~.

After spending quite some time, I discovered that RULE "two" does not match at the very end, i.e. the target concept of the expression I-asmValue;asmValue~ does not match the target concept of the left hand side of the rule.
@sjcjoosten: can you arrange an error message that is more helpful (e.g. that points this out) rather than the (unhelpful, albeit like correct) message that asserts a disambiguity in I?

[sjcjoosten]

I'm afraid not, there is no way for me to determine the type of (I-asmValue;asmValue~) without knowing the type of the I used there, since - takes the type of its first argument. Solving the ambiguity first should help you get the error message you wanted.

[RieksJ]

I am flabbergasted. In the rule I occurs three times, two of which have their concept specified. For the third I, it seems obvious to me that its concept should be Assignment - I do not see what other concept could possibly be used here since Assignments are not in any CLASSIFY statement. In a similar fashion, I cannot think of any other possible type for (I-asmValue;asmValue~) than [Assignment*Assignment]. It is not ambiguous at all. Still, you tell me that for you there is no way to determine the type. So what am I missing here, or what?

Then, the generated error message talks about an ambituity with some I. However, as I said in the original ticket, the error is that the types of the expressions at the left and right of |- do not match (at the target position. That's not an ambiguity, but simply wrong.

[hanjoosten]

Stating it seems obvious to me... is normally good enough for a modeller to avoid errors like this. However, it isn't well enough for a machine.

If I look at the rule, I could formulate something completely different:
It seems obvious to me that its concept should be Variable . This is quite easy to see, because the target of I must match the target concept of (I[Variable]-I[Concern]).

The conclusion is that there is an error in the script. I cannot be typed. Luckily for us all, the typechecker does a great job in finding all errors. In most cases, an error message is produced that is clear at first sight. In this case it is arguable if the error message is is guessing the intent of the modeller well enough. However, it is a result of the way the typechecker is implemented. I agree with Bas that it is not a reason to change that implementation.

This leaves us with two alternatives for this issue. We could either close it, or leave it open. In both cases, nothing will be changed at the error message level. Leaving it open only causes this issue to appear on the backlog, knowing that nothing will be done for it ever.

[RieksJ]

I agree that the type checker does a great job in finding all errors. The next thing is that it should point the user in a right direction. If I follow the advise of the error message, the error is not solved. Therefore, the errormessage is wrong. I disagree with anybody that insists that it is acceptable that tools provide guidance for solving an error that, when followed, does not solve that error. If nothing is done about that, then we should be continuously reminded of this. Therefore, I reopen this ticket.

[hanjoosten]

@RieksJ suggests that it is possible that in all cases a single message could give guidence that is well enough to solve an error. The current implementation cannot do that. In cases like this, where there is a combination of mistakes in the script, i doubt that it is possible at all. To do an execellent job in such cases, one must know that no guidence can be generated. However, the current implementation cannot do so either. As long as no one has any clue about how to implement this wish, no progress can be made at all for this issue. As each open issue has a maintenance cost, I suggest to close it.

[RieksJ]

What I suggested is that if an error message provides guidance in some case, such guidance should actually help to solve the problem rather than sending users into the wrong way. The error message I mentioned sent me into the wrong way.

For me, I can live with the way it is (even if it irritates me at some point). However, for students and other &-apprentices meaningful, i.e. helpful error messages seem quite important to me. I suggest @stefjoosten to decide whether to close this ticket or do something about it.

[stefjoosten]

I had the same discussion with @sjcjoosten in the past. In my recollection they were as fiercly debated as above. I'm still not sure what causes the confusion. But now I have a hunch...

edit by sjcjoosten: this hunch has been moved to #688

[RieksJ]

The error message that was provided only points to one error, where there are more. The suggestions point to the 'wrong' direction (from a user point of view) because none of them will result in the rule becoming correct.

Would it be possible to check the suggestions of the type-checker to see if either/any of them makes sense (i.e. would actually result in a type-correct RULE rather than some non-obvious partial expression), and if not, it might provide a more general kind of instruction for fixing the issues, which in this case might be something like:

Error at symbol () in file BugX.adl at line 10 : 51
  Cannot disambiguate: I
  However, I also cannot find any possible solutions for disambiguation.
  Please check the rule carefully for erroneous types
( mogelijk gevolgd door nog wat suggesties als je die kunt verzinnen ).

Whatsay?

[sjcjoosten]

This makes a lot of sense and sounds like a great idea to me. I might be able to detect that the 'Cannot disambiguate' arises because of a type error that I can't yet point at exactly. How would this be as an error:

Error at symbol () in file BugX.adl at line 10 : 51
  Cannot disambiguate: I
  Please add a signature.
  This arises trying to match Concern and Variable, which are incompatible.
  There may not be a signature that solves the error,
  providing the right signature may improve the error message.

In case there is an ISA between the two (or more) concepts, we could write (in place of which are incompatible): of which X is the most generic and Y is the most specific. That doesn't apply to this example but I'm adding it as a note in case the above seems like a good solution.

[RieksJ]

This error message suggestion of @sjcjoosten considers the possibility that there is no signature that would produce a correct expression, which is an improvement over the current situation (and likely a very quick fix!).

However, helping the modeler consists of being as precise as can be. Therefore, I would like to see different messages for the case where adding a signature would result in a type-correct rule (preferably with suggestions for all concepts that would actually produce a type-correct rule) and the case where no concept exists that, when added as a signature, would produce a type-correct rule. For the first category, the current message suffices. For the latter category, I would suggest something like

Error at symbol () in file BugX.adl at line 10 : 51
  Cannot disambiguate: I, and there is no way that it can be disambiguated.
  This is due to the use of relations that ... (invullen)
  You may want to check the signatures of all relations involved in this rule.

And while this message may not yet be ideal, I do consider it an improvement over @sjcjoosten's suggestion.

[sjcjoosten]

I want to avoid writing `there is no way', as there might be one, it's just that I cannot (within reasonable performance) find it if it exists. Also, I have no idea what to put on the ....

On the second part of your message: I would not change the message if adding a signature is likely to result in a type-correct rule.

[RieksJ]

Ok. How about:

Error at symbol () in file BugX.adl at line 10 : 51
  Cannot disambiguate: I, and there is no obvious way that it might be disambiguated.
  Such situations are known to be caused by multiple type-errors in a single expression.
  Please carefully check the signatures of all relations involved in this rule.

[sjcjoosten]

Great, I can definitely do that (except I won't be sure whether this occurs in a rule or not), and maybe I can do better, tell me what you think:

Error at symbol () in file BugX.adl at line 10 : 51
  Cannot disambiguate: I, and there is no obvious way that it might be disambiguated.
  Such situations are known to be caused by multiple type-errors in a single expression.
  In this case, such a type conflict occurs between the concepts Concern and Variable.
  Please check the signatures of all relations involved.

[RieksJ]

Having given it some thought, I am not convinced that the line In this case, such a type conflict occurs between the concepts Concern and Variable., is helpful to the programmer. People like me expect error messages to state the kind of error that is detected, and provide information that helps me find and correct it. This line does neither, leaving me in a confused state as to what it is trying to convey. I suggest to leave the line out.

Perhaps this might be an improvement (where the second line in the message sums up the concepts that appear in the expression, and fail to make the expression type-correct):

Error at symbol () in file BugX.adl at line 10 : 51
  Cannot disambiguate: I, and there is no obvious way that it might be disambiguated.
  (None of the concepts 'Concern', 'Variable' or 'Assignments' will solve this issue).
  Such situations are known to be caused by multiple type-errors in a single expression.
  Please carefully check the signatures of all relations involved in this rule.

[github-actions]

This issue is stale because it has been open 5 years with no activity. Remove stale label or comment or this will be closed in 30 days.

[github-actions]

This issue was closed because it has been stalled for 30 days with no activity.