#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

#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 Richard Eisenberg ): In [changeset:"e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9/ghc" e7985ed2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9" Update levity polymorphism This commit implements the proposal in https://github.com/ghc-proposals/ghc-proposals/pull/29 and https://github.com/ghc-proposals/ghc-proposals/pull/35. Here are some of the pieces of that proposal: * Some of RuntimeRep's constructors have been shortened. * TupleRep and SumRep are now parameterized over a list of RuntimeReps. * This means that two types with the same kind surely have the same representation. Previously, all unboxed tuples had the same kind, and thus the fact above was false. * RepType.typePrimRep and friends now return a *list* of PrimReps. These functions can now work successfully on unboxed tuples. This change is necessary because we allow abstraction over unboxed tuple types and so cannot always handle unboxed tuples specially as we did before. * We sometimes have to create an Id from a PrimRep. I thus split PtrRep * into LiftedRep and UnliftedRep, so that the created Ids have the right strictness. * The RepType.RepType type was removed, as it didn't seem to help with * much. * The RepType.repType function is also removed, in favor of typePrimRep. * I have waffled a good deal on whether or not to keep VoidRep in TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not* represented in RuntimeRep, and typePrimRep will never return a list including VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can imagine another design choice where we have a PrimRepV type that is PrimRep with an extra constructor. That seemed to be a heavier design, though, and I'm not sure what the benefit would be. * The last, unused vestiges of # (unliftedTypeKind) have been removed. * There were several pretty-printing bugs that this change exposed; * these are fixed. * We previously checked for levity polymorphism in the types of binders. * But we also must exclude levity polymorphism in function arguments. This is hard to check for, requiring a good deal of care in the desugarer. See Note [Levity polymorphism checking] in DsMonad. * In order to efficiently check for levity polymorphism in functions, it * was necessary to add a new bit of IdInfo. See Note [Levity info] in IdInfo. * It is now safe for unlifted types to be unsaturated in Core. Core Lint * is updated accordingly. * We can only know strictness after zonking, so several checks around * strictness in the type-checker (checkStrictBinds, the check for unlifted variables under a ~ pattern) have been moved to the desugarer. * Along the way, I improved the treatment of unlifted vs. banged * bindings. See Note [Strict binds checks] in DsBinds and #13075. * Now that we print type-checked source, we must be careful to print * ConLikes correctly. This is facilitated by a new HsConLikeOut constructor to HsExpr. Particularly troublesome are unlifted pattern synonyms that get an extra void# argument. * Includes a submodule update for haddock, getting rid of #. * New testcases: typecheck/should_fail/StrictBinds typecheck/should_fail/T12973 typecheck/should_run/StrictPats typecheck/should_run/T12809 typecheck/should_fail/T13105 patsyn/should_fail/UnliftedPSBind typecheck/should_fail/LevPolyBounded typecheck/should_compile/T12987 typecheck/should_compile/T11736 * Fixed tickets: #12809 #12973 #11736 #13075 #12987 * This also adds a test case for #13105. This test case is * "compile_fail" and succeeds, because I want the testsuite to monitor the error message. When #13105 is fixed, the test case will compile cleanly. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12973#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler