error-messages icon indicating copy to clipboard operation
error-messages copied to clipboard

`Parse error in pattern` for operator-style data constructors is vague

Open MorrowM opened this issue 4 years ago • 2 comments

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.

MorrowM avatar Sep 09 '21 05:09 MorrowM

The given match could also be a mistake for a pattern binding like F x : xs = …, even though that was not the case here.

Melvar avatar Sep 09 '21 16:09 Melvar

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.)

Ericson2314 avatar Feb 18 '22 07:02 Ericson2314