[GHC] #13917: The line on which to locate the error indication is bad.

#13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ 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 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13917 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): 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 ()) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13917#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13917#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann):
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 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13917#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): 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? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13917#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13917#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): 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? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13917#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13917#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13917: The line on which to locate the error indication is bad. -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): 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! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13917#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC