[GHC] #12973: No levity-polymorphic arguments

[GHC]

#12973: No levity-polymorphic arguments
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:  goldfire
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:
                                     |  LevityPolymorphism
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 goldfire):

 Something struck in the night. Time will tell if it was wisdom.

 The idea is this: the representation choice of an argument is properly a
 property of the ''function'', not the ''argument''. So, in Core at least,
 when examining `f (x |> co)`, we care about the argument type of `f`, not
 that of `x` or `co`. (Of course, if it's well typed, the right-hand type
 of `co` matches the argument type of `f`.) So the Core levity polymorphism
 check does ''not'' look under coercions. However, this means that the code
 generator must also not look under coercions when compiling arguments
 (that is, when converting to ANF). Does this already happen? Perhaps, as I
 look at !CorePrep.

 But then is this respected further on down the compilation chain? (That
 is, how are coerced arguments handled in STG and beyond?) I do see that we
 simply drop casts in !CoreToStg; no surprise there. And I suppose that, at
 this point, we're already in ANF form, so any arguments are bound to ids
 that have the right type.... so maybe it's all OK. I'd love confirmation.

 Even if this all works out at the Core level, we still have a type
 inference challenge. Maybe the solution is simply to punt, arguing that
 the user is playing with fire and so sometimes will get burnt. By "punt"
 here, I mean that GHC just has a little unpredictability in this area.
 (Indeed, this is already the case, as discussed in the paper around
 trouble generalizing levity variables.)

 Maybe this is the real wisdom here: keep calm, carry on, and hope it all
 works.

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