`Parse error in pattern` for operator-style data constructors is vague
Consider the following GHCi session:
ghci> f x:xs = print(x, xs)
<interactive>:162:1: error: Parse error in pattern: f
This is a function that a beginner I was talking to asked about. They (understandably) didn't understand what the issue was, or how to fix it. The error message doesn't help much here. It does mention something about a pattern, though.
The solution, of course, is to add parentheses around the pattern. f (x:xs) = print(x, xs). I think it would be an improvement to reflect this in the error message:
<interactive>:162:1: error:
Parse error in pattern: f x:xs
Hint: Constructor patterns with arguments must be surrounded by parentheses
Note that this is not as bad in the case of non-operator constructors:
ghci> data Foo = Foo Int
ghci> f Foo x = x
<interactive>:2:3: error:
• The constructor ‘Foo’ should have 1 argument, but has been given none
• In the pattern: Foo
In an equation for ‘f’: f Foo x = x
I think we'd still benefit from including the hint. I think it's worded loosely enough to be understood as a possible solution, not an absolute one, so even if they just forgot an argument it'd be fine. But I'm more concerned about the operator case.
I think good parse error messages are important for a smooth learning experience, and the state of parse error messages today is fairly poor in my opinion. It'd be nice to see more of these sorts of issues opened here, like #14 , for example.
The given match could also be a mistake for a pattern binding like F x : xs = …, even though that was not the case here.
This is yet another case where I want GHC to first parse a super permissive, AST, and then refine.
f x : ds = print (x, xs)
is in fact a perfectly legal equation; it just turns out that function definitions are not, in fact, arbitrary equations. If we parse arbitrary equations first, we can do much nicer errors.
(Also this is one reason I wish we could disable function binds, and make the user use a lambda, but I digress such -XNo.... obsessions are out of scope.)