[GHC] #13893: Improved Help for Control.Concurrent and Control.Exception when "variable not in scope"

[GHC]

#13893: Improved Help for Control.Concurrent and Control.Exception when "variable
not in scope"
-------------------------------------+-------------------------------------
        Reporter:  vanto             |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Poor/confusing    |  Unknown/Multiple
  error message                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by slyfox):

 Replying to [comment:5 vanto]:
 > Replying to [[span(style=color: #FF0000, slyfox )]]:\\
 > >Why take preference of packages coming with ghc in this case?\\
 > Because these are the main libraries, of course. Those related to
 Haskell standard Prelude. (e.g Data.Char, Control.Applicative,
 Control.Monad, Data.Monoid, Data.Foldable and so on)\\\\

 These functions are not in haskell's (nor in GHC's) Prelude module.
 Otherwise you
 would get a working program instead of errors about missing symbols.

 Let's pick a simple example: **fromList**. Which module(s) should GHC
 suggest for these?

 > >It's not always the case that user wants to use base's primitives.\\
 > so what?\\\\

 It meas that suggestion will not be correct and will mislead user to add
 wrong module
 into imports instead of stating the fact about missing import.

 > >I would say suggesting incorrect module imports would lead to more
 confusion.\\
 > You do not trust the compiler?\\
 > Dr. Bjarne Stroustrup said that you should always trust the answers
 given by the compiler. And he's right. So that GHC gives the right
 answers, you have to program it in this way. it is obvious.\\
 > If the compiler is able to recognize the variables that belong to a
 module ( which I quote above) it must be able to suggest the appropriate
 module.\\
 > __And to go further if the compiler is able to suggest the right module
 it must be able to compile it independently of the programmer.__\\
 > The compiler is able to recognize many of the leading pragmas (file-
 header LANGUAGE pragmas).
 >
 > Experiencing yourself by writing a few expressions that need their
 pragmas to work, but do not write them and compile the file.
 > You will be surprised to see how well the compiler is able to recognize
 them and to propose them to the programmer to insert them in the program.
 > Even changes the order of the functions in the file. Moves the first
 function to the end for example and writes the function from end to
 beginning. Done with functions using various pragmas and you will be even
 more surprised.\\
 > __What the compiler can do is marvellous.__\\\\

 In order to earn user's trust compiler should have minimum of false
 positives.
 Missing LANGUAGE pragma detection works differently from symbol
 resolution.
 GHC already knows all the syntax it can parse.

 The lexer branches guarded by LANGUAGE pragmas have conditional code of
 either
 parsing expressions correctly or reporting an error about missing LANGUAGE
 pragma.

 Even that simple idea and implementation does not always work correctly
 due to language extensions having a syntactic overlap.

 > >Which procedure should define which packages (and modules) are blessed
 to deliver suggestions for symbols?\\
 > I do not quite understand the question.\\
 > But if you talk about the code that makes it work it would be the same
 procedure which defines the pragmas I suppose or another choice that
 remains to be defined.\\\\

 LANGUAGE pragma detection does not require loading modules not used by the
 program.
 Suggesting symbols would require such loading. The question is about list
 of such
 autoloaded modules.

 > >As ticket's subject is worded why Control.Concurrent and
 Control.Exception should be threated special?\\
 > Not at all. These modules are examples. The subject is badly defined in
 the ticket.

 Please reword the ticket description.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13893#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler