#7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: 3990 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bgamari): This morning I was thinking about how this might work. Would unpacking be restricted only to single-constructor polymorphic types? For instance, if I had, {{{ data Poly a = MkP !Bool {-# UNPACK #-} !a | MkP2 data Mango = MkMango {-# UNPACK #-} !(Poly Int) }}} Would I want to produce a representation that is the product of all of the unpacked variants? e.g.. {{{ data MangoRep = MangoRep1 !Bool !a | MangoRep2 }}} Or would we want to simply not unpack multi-constructor types? This seems to be how monomorphic types are currently handled, if I understand the code correctly. Moreover, how would a pattern match against an unpacked polymorphic type be lowered? Would we want to re-box `Poly` when pattern matching on `Mango`? Alternatively, we could somehow specialize functions on `Poly` to take the unboxed representation. Thoughts? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7647#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler