#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 goldfire): simonpj says:
A simple once-and-for-all analysis on the DataCon will establish how to do the matching, which type args to retain, etc.
So a `DataCon` will have this info stored in it? It might be non-trivial! For example: {{{ data T a where MkT :: F a -> T a }}} If `F` is not injective, we would need to store the choice for `a`. Even if it is injective, it may be more convenient to store the choice for `a`. And then there are examples like {{{ data T2 a where MkT2 :: Maybe (Either Bool a -> a) -> T2 a }}} where the relationship between the constructor field's type and the choice for `a` is non-trivial. However, perhaps a use of `tcMatchTy` or one of its friends when constructing the `DataCon` is enough to sort this out. If we successfully do this for data constructors, it should not be hard to do the same for poly-kinded type constructors. I'm specifically thinking about the redundant `RuntimeRep` arguments to unboxed-tuple type constructors. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12618#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler