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