#15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): The singleton levity trick would work, but it seems a little disappointing that users would need to take a (admittedly small) performance hit to get this extra polymorphism. I retract part of my claim about levity polymorphic data constructors. Here is what would be possible/impossible without any changes to GHC's codegen and runtime: - Defining levity-polymorphic fields in data construtors. YES - Constructing a value with such a data constructor where the levity is monomorphic. YES - Constructing a value with such a data constructor where the levity is polymorphic. NO - Casing on such a value in a levity-monomorphic or levity-polymorphic settings. YES This feels consistent with your earlier claim about the binder rule being relaxable but the function argument rule not being relaxable. Casing on a data constructor introduces a binder but applying a data constructor is applying a function. However, casing on a data constructor to get out a levity polymorphic field still isn't particularly useful, since there is basically nothing interesting you can do with the value at that point. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15532#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler