The line on which to locate the error indication is bad.

module Qwer where

a = {-# LANGUAGE KindSignatures #-}

main :: IO ()
main = print (if True then () else ())

Reply from GHC\\

Prelude> :l qwer.hs
[1 of 1] Compiling Qwer             ( qwer.hs, interpreted )

qwer.hs:5:1: error:
    parse error (possibly incorrect indentation or mismatched brackets)
  |
5 | main :: IO ()
  | ^
Failed, modules loaded: none.

The error is located on line 3.\\ GHCi, version 8.2.0.20170507

Trac metadata

Trac field	Value
Version	8.0.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

mentioned in issue #13918

No. This program (with a change in line 5 onle) is valid:

module Qwer where

a = {-# LANGUAGE KindSignatures #-}

  main :: IO ()
main = print (if True then () else ())

Replying to [[span(style=color: #FF0000, j.waldmann )]]\\ Interesting! I can do better.\\

module Qwer where

a = ({-# LANGUAGE KindSignatures #-})

main :: IO ()
main = print (if True then () else ())

One more thing. If I change your code like that\\

module Qwer where

a = ({-# LANGUAGE KindSignatures #-})

  main :: IO ()
main = print (if True then () else ())

GHC says\\

Prelude> :l qwer.hs
[1 of 1] Compiling Qwer             ( qwer.hs, interpreted )

qwer.hs:3:5: error:
    * Couldn't match expected type `IO () -> IO ()'
                  with actual type `()'
    * The function `()' is applied to one argument,
      but its type `()' has none
      In the expression: () main :: IO ()
      In an equation for `a': a = () main :: IO ()
  |
3 | a = ({-# LANGUAGE KindSignatures #-})
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
Failed, modules loaded: none.

Anyway the code you wrote is not pretty. Clarity of a program is very important especially in software maintenance.

not pretty

Please. It is not the compiler's task to check prettiness. There are extra tools for that, like https://hackage.haskell.org/package/hlint

Here we go astray. We realize that by moving main of two spaces to the right there is a bug when the expression of a is put between brackets (e.g (...)).\\ On the other hand if main has its usual place and the brackets are not put around the expression of a there is a bug. And the designated line is not the right one in my opinion.\\ What does a member of the Committee think?

In the case of a concrete syntax error (as opposed to a type error), I believe that the location of the error is the first character that fails to parse. In the case of the original program, that character is the m in the first occurrence of main, as reported by GHC. GHC does not try to find the line where the fix needs to be applied, and I don't think it should, for parse errors.

Replying to [[span(style=color: #FF0000, goldfire )]]\\ OK. It is preferable to indicate the line where there is the syntax error. And the compiler does so in the majority of cases. Here what is the best solution?\\ If the error is on the line main, do you move main to the right of two spaces? And so you create disorder in your code, or you correct the line above? If you correct the line above, GHC should indicate this line for correction. But perhaps this is too difficult to code?\\ In this specific case what do you suggest?

The correction to the code is irrelevant for parsing errors: GHC just reports where it first encounters a parsing error. There is no promise that a fix is available on that line -- indeed, in this case it's just a stroke of luck that there is.

While it's conceivable to imagine some program analysis tool that uses heuristics to do what you want -- make the suggestion an expert Haskeller would make -- that is well beyond the scope of what GHC does. The amount of engineering would be huge. Perhaps this kind of tool would pay off in the long run (imagine always having an "expert Haskeller" at your side while programming!), it doesn't seem necessary to tie such a tool into GHC.

So, my recommendation is to treat the current behavior as correct and move onto other problems.

Replying to [[span(style=color: #FF0000, goldfire )]]\\ No, here it is not a matter of doing an analysis by the compiler. Here we find ourselves in a situation that no one imagined except me. And it seems that you do not understand this situation and that it does not interest you. It's amazing!

added error messages label

added Pnormal label