[GHC] #12618: Add saturated constructor applications to Core
GHC
ghc-devs at haskell.org
Mon Sep 26 02:37:07 UTC 2016
#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
More information about the ghc-tickets
mailing list