#11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: sweirich@…, dimitris (added) Comment: The issue with un-saturated type function is to do with abstraction. What if you had {{{ (/\(a:: * -> *). blah) F }}} where `F` is a type function. Well bad things, if you can decompose applications of `a` in `blah`. I think that's the only thing that can go wrong with un-saturated unlifted type constructors. What if we said {{{ (/\(a :: * -> *). blah) Array# }}} Would that be OK? Well, no: `Array# Int` is an unlifted type, not `*`. So it's ill-kinded. But I think this would be fine {{{ (/\(a :: TYPE 'PtrRepLifted -> TYPE 'PtrRepUnlifted). blah) Array# }}} Inside `blah` a variable `x :: a Int` would be an unlifted type, evaluated call-by-value, just as it should. Moreover stranger things like {{{ (/\(a :: Type 'PtrRepLifted -> TYPE 'VoidRep). blah) State# }}} Now inside blah a variable `x :: a Int` would be an unboxed zero-width void thing. Just right. In short I think this is absolutely fine. We don't even need to do anything! (I vote for the above patch.) All we need is someone to come up with a proper account of runtime-rep polymorphism. Kenny? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11736#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler