[GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module

[GHC]

#14963: ghci -fdefer-type-errors can't run IO action from another module
-------------------------------------+-------------------------------------
        Reporter:  elaforge          |                Owner:  tdammers
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.4.2
       Component:  GHCi              |              Version:  8.4.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by tdammers):

 Replying to [comment:20 elaforge]:
 > Surely those people's workflows are already broken by the fact that you
 can't evaluate much of anything without causing a panic.
 >
 > If they are just loading the modules to check types and not actually
 running them, then they don't need `-fdefer-type-errors` in the first
 place.  So if someone's tool is thrown by an extra warning msg, they can
 probably just remove the flag.  I also think it's reasonable to expect
 tools to be robust against unexpected messages at startup before the
 prompt comes.

 The use case for `-fdefer-type-errors` is so that you can run (and test)
 your module even when parts of it don't typecheck yet. E.g. suppose you
 write this:

 {{{#!hs
 module Pluralize
 where

 suffix :: Int -> String
 suffix 1 = ""
 suffix _ = "s"

 pluralize :: Int -> String -> String
 pluralize i s = s ++ i -- TODO
 }}}

 ...then you might want to load it into GHCi to play with the `suffix`
 function, or you may want to run unit tests on it, even though `pluralize`
 doesn't work yet (and doesn't typecheck).

 Deferring type errors is *especially* (some would argue *only*) useful in
 an interactive REPL: there isn't really a sharp workflow distinction
 between "compile time" and "runtime", so it is less important to produce
 type errors at compile time.

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