#12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: 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 nomeata): I guess the solution to that is adding a type class, such as {{{ class CompressArgs b where unpackArgs :: Expr b -> Arity -> [Expr b] -> [Expr b] unpackArgs _ _ l = l packArgs :: Expr b -> [Expr b] -> [Expr b] packArgs _ l = l }}} or alternatively {{{ class HasType a where hasType :: Expr a -> Type }}} and adding instances for the two type of binders we have (`Var` and `TaggedBndr t`). With a few constraints added in various places (four modules only), this also compiles. It seems the remaining bit is to solve the staging issue: The instance should live in `CoreSyn`, but requires `expType` in `CoreUtils`. If that can be solved, the feature could be added quite painlessly. Then, in all places where the expression is traversed, one can any time make the decision to work on `Apps` directly, instead of `App`. I expect we’d get the memory performance boost we want (exciting!), but I also expect that this encoding/decoding in every traversal will cost runtime. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12618#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler