Improve error message for: "The type 'int' does not support the operator 'DivideByInt'"

[KevinRansom]

This was originally opened on CodePlex by latkin

Today this happened to me:

Microsoft (R) F# Interactive version 12.0.20809.1
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> [|2;4;6;8|] |> Seq.average;; 

> [|2;4;6;8|] |> Seq.average;;
  ---------------^^^^^^^^^^^

stdin(1,16): error FS0001: The type 'int' does not support the operator 'DivideByInt'

I was surprised to discover that int does not support DivideByInt. Since many times I have successfully divided ints by other ints.

I think we should either:

• Make all numeric types that are divisible by int support DivideByInt or
• improve the error message so that it’s not quite so head scratching.

comments dsyme wrote Jun 3, 2014 at 6:02 AM +1 for a better error message

[pbachmann]

A focus area that follows on from the ChatGPT example might be:

Could ChatGPT have given a better answer? What would that answer look like?

I suspect people looking at everyone's answers to that focus might form doubts about ChatGPT being a great learning tool.

I also suspect that the original designers of F# will protest that ChatGPT's answer is more an insult than an explanation.

Then would come the inevitable and delicious question of why ChatGPT got it so wrong?

[pbachmann]

Two weeks, no apparent progress.

Doesn't anyone want to say whether ChatGPT nails it with its answer? And if it doesn't, what a much better answer would look like?

[vzarytovskii]

Two weeks, no apparent progress.

Doesn't anyone want to say whether ChatGPT nails it with its answer? And if it doesn't, what a much better answer would look like?

I don't think anyone was actively looking into this one specifically. It's also a bit slow now since it's holiday season and people tend to take some time off.

But diagnostics "area" in general (not only this particular issue) needs a systematic approach (or multiple), so we can argue about it.

[Martin521]

Two weeks, no apparent progress.

Not a long time for a ten-year-old issue ;-)

But I have been investigating the implementation side meanwhile, and that leads me to the following proposal.

Discussion should continue, certainly the discussion on a systematic approach for diagnostics.

At the same time, we can perhaps close this old issue by doing exactly what its title says. I propose, at least as a first step,

• to restrict the scope to built-in constraints such as DivideByInt and get_Zero,
• to restrict the scope to indirect constraints, i.e. exclude cases like f above where the constraint is defined in the operator itself
• to not cover cases like System.DateTime.Now + System.DateTime.Now as it will be another level of difficulty in implementation and it not in the scope of the original issue,
• to not provide more additional information than the constraint source, as adding, for example, also all other constraints of that source will create another level of difficulty in the implementation
• to go with a simple error message of the type The type 'int' does not support the operator 'DivideByInt' as required by 'List.average'

I believe this solves what the issue title says. By being directed to 'List.average', most developers will move their mouse pointer to that function and see all constraints in full beauty.

Further improvements can then be tackled separately.

Unless I hear a lot of opposition, I will start working on a PR for that scope.

[pbachmann]

Since you are doing almost all the work around here @Martin521, I am reluctant to disagree with you. Nevertheless, you asked for responses, so I guess I must give you one.

You say that currently there is an error message: error FS0001: The type 'int' does not support the operator 'DivideByInt'

And you want to change it to: error FS0001: The type 'int' does not support the operator 'DivideByInt' as required by 'List.average'

You also say, and I agree, that by referring explicitly to List.average, most developers will hover their mouse over that function and will see all the constraints.

Then you say this "solves the problem" of the error message needing improvement.

Doing my best to be positive, I agree that by presenting all the constraints in the tooltip, the user may get a better feeling for how constraints work.

But why end our exploration there? Can't we ask ourselves what other things developers might think when they see the list of constraints associated with List.average? And what will they make of other information they see in the tooltip? And what will they do if they're working in F# interactive and don't get tooltips?

I have already suggested multiple times that a "back to basics" approach might be called for, ie. a gentle, good-natured exploration of key questions such as:

1. Who sees the message?
2. What do they do now when they see the message?
3. What do we want them to do instead?

It has already been pointed out that ChatGPT, a robot, does a credible job of explaining the message. This, in turn, has raised the rather urgent and pressing question of whether we can do better than the robot.

[Martin521]

Thanks @pbachmann for your comment. At the moment, though, my goal is not to do better than a robot, but just to make a small step by improving the current error message. That should not stop anybody from doing more.

[Martin521]

While working on the implementation, I found we should do the following:

• This issue is about "indirect" operator constraints, meaning that a built-in constraint that is coming from an operator is exposed by a function or method that uses the operator. Note that in the case of DivideByInt (and a few others) the name of the operator and of the constraint member are the same. In other cases (like abs, sin, sqrt) the constraint member name is different (Abs etc). For the "indirect" case, we want to point to the exposing function or method to make the error message more understandable. Given that the operator itself is not visible here, the error message The type 'int' does not support the operator 'DivideByInt' as required by 'List.average') makes no longer sense. I think it should be something like 'List.average' does not support the type 'int', because the latter lacks the required (real or built-in) member 'DivideByInt' (and similar of course for Truncate, get_Zero etc when used by a library function).
• Just because it is easy to do, I also want to change the error message for abs 1u from The type 'uint32' does not support the operator 'Abs' to The type 'uint32' does not support the operator 'abs'. (Because the operator is abs, while Abs is the constraint member name.) Same of course for sin, cos, sqrt etc.
• Everything else should (for now) stay as is.

[Martin521]

Now that #16304 has landed with SDK 8.0.200, I think we can close this issue.

[vzarytovskii]

Now that #16304 has landed with SDK 8.0.200, I think we can close this issue.

Yeah, I suppose we can, thanks!