[GHC] #14765: Levity polymorphism panic

[GHC]

#14765: Levity polymorphism panic
-------------------------------------+-------------------------------------
        Reporter:  dfeuer            |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.5
      Resolution:                    |             Keywords:
                                     |  LevityPolymorphism
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash or panic                     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 A few thoughts:

 * I really don't like having `isUnliftedType` return False for levity
 polymorphism. Panicking is the right behavior. Anything else might mask
 bugs.

 * How would the new `mkCoreApp` work? Would it check its argument for
 levity polymorphism and then react accordingly? This check is not
 necessarily cheap, and it would be redundant with other checks for LP.

 * We could make the new `mkCoreApp` monadic and have it do the only LP
 check. But then it would need to take the undesugared argument, so that
 error messages can be at all sensible. That would work in several cases,
 but sometimes it's not so easy.

 * You're right that returning `()` is gross. Perhaps returning `undefined`
 is better.

 * `dsWhenNoErrs` uses `askNoErrsDs` which does indeed use `tryM`. But
 there's no great reason `askNoErrsDs` needs to allocate fresh refs for
 messages, given that messages are ''always'' propagates in `askNoErrsDs`.
 Perhaps we could just make that more efficient by not using `tryM`.

 Bottom line: I don't love the current design. But the devil is in the
 details, and I'm not yet convinced about any new design either. We'd have
 to try it and see. (I am convinced enough that `undefined` is better than
 what we have now.)

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