Improve error reporting: Need parentheses on arguments

[isaacabraham]

What

The following code snippet gives an error which is very confusing for beginners.

let add a b = a + b
let multiply (a:int) (b:int) = a * b

multiply 5 add 5 10
^^^^^^^^^^^^^^

error FS0003: This value is not a function and cannot be applied.

(as an aside I had to explicitly type annotate multiply otherwise the compiler infers a completely different signature for it!)

Why

The issue (from what I understand) is that F# can't correctly resolve the precedence of the function calls i.e. It picks (multiply 5 add) 5 10 instead of multiply 5 (add 5 10). The solution is indeed to explicitly wrap the add expression in parentheses, whereby the compiler happily figures everything out.

How

In a perfect world

Invalid function arguments. The compiler cannot understand the order of function calls and arguments from this callsite. Did you mean to pass the result of "add 5 10" as an argument into "multiply"? If so, wrap the "inlined" function call in parentheses e.g. multiply 5 (add 5 10)".

Next option

I suspect that this would be difficult to do - if so, how about a more generic error message like:

Invalid function arguments. The compiler cannot understand the order of function calls and arguments from this callsite. Are you passing the result of one function call directly into another function call? If so, consider wrapping the inline function call in parentheses e.g. "foo a bar b" should be rewritten as "foo a (bar b)".

Last option

Another approach is to consider that the compiler seems to be assuming this precedence:

(multiply 5 add) 5 10

In such a case, why doesn't the compiler give an error such as:

multiply 5 add 5 10
           ^^^

This expression was expected to have type
    'int'
but here has type
    'int -> int -> int'

Whilst not perfect, I think that this would be a little better than the current error message.

[cartermp]

The last approach is interesting, as this is the sort of error I'd expect a bit more. For reference, OCAML will say:

Error: This function has type int -> int -> int
It is applied to too many arguments

Which also isn't ideal, but does hint that not everything matches up.

[cartermp]

I think the most baffling part of the error message is the "this value" bit. There's no hint about which value it is. That could probably be corrected.

[isaacabraham]

I think the most baffling part of the error message is the "this value" bit. There's no hint about which value it is. That could probably be corrected.

@cartermp but how - in this case I imagine that the value is the result of calling the function, which in this case has no name? Same with partially applied functions.

[cartermp]

Some notes after doing some user studies and seeing this come up multiple times:

• argv.Length -1 vs. argv.Length - 1

  Hugely confusing, as -1 is being treated as an argument to Length which isn't a function

• printfn "%s" arg.Reverse()

  Also hugely confusing for people, so far not a single person was able to deduce that they needed to wrap with parentheses

[isaacabraham]

@cartermp Do you think it's possible to come up with a list of 3 or 4 of the most common causes of this error?

[isaacabraham]

@cartermp that second one (arg.Reverse()) is actually a "reasonable" error message but just needs to be made more user-friendly:

e.g This is the current message Successive arguments should be separated by spaces or tupled, and arguments involving function or method applications should be parenthesized

(can the first case actually occur? when?)

Replace with something like

Incompatible arguments. If you are passing an argument to a function that is itself the result of calling a function, ensure you wrap it in parentheses e.g. foo bar() must be written foo (bar()). Otherwise, the compiler will assume that bar and () are separate arguments being passed to foo.

Although related, I would suggest opening a separate issue for that?

[cartermp]

@isaacabraham

Do you think it's possible to come up with a list of 3 or 4 of the most common causes of this error?

Probably not, since we don't have telemetry in the compiler. The two were from 9 user studies, but even then that's just a sample and it's influenced by the task I gave them.

Thanks for pulling the second case into a second bug report.

[penguid]

printfn "%s" arg.Reverse()

Also hugely confusing for people, so far not a single person was able to deduce that they needed to wrap with parentheses

@cartermp Any possibility of reconsidering Allow argument expressions to omit parentheses #174 maybe for F# 5.0?

[cartermp]

@penguid Nope, that one's been declined.