[GHC] #13848: Unexpected order of variable quantification with GADT constructor

[GHC]

#13848: Unexpected order of variable quantification with GADT constructor
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler (Type    |              Version:  8.0.1
  checker)                           |             Keywords:
      Resolution:                    |  TypeApplications
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 simonpj):

 Yes you are right.   So yes, we have to put more info in the
 `IfaceConDecl`.

 Putting in the wrapper type doesn't feel right -- duplicates too much.

 Better to put in the original tyvars.

 And in that case we may as well record them in the `DataCon` too, as you
 suggested earlier.  Then we wouldn't need to pass them to `mkDataConRep`
 after all, because they'll be in the `DataCon`.

 One fiddly thing I'm not sure about: in the declaration of `IfaceConDecl`
 we see
 {{{
 data IfaceConDecl
   = IfCon {
         ifConName    :: IfaceTopBndr,                -- Constructor name
         ifConWrapper :: Bool,                   -- True <=> has a wrapper
         ifConInfix   :: Bool,                   -- True <=> declared infix

         -- The universal type variables are precisely those
         -- of the type constructor of this data constructor
         -- This is *easy* to guarantee when creating the IfCon
         -- but it's not so easy for the original TyCon/DataCon
         -- So this guarantee holds for IfaceConDecl, but *not* for DataCon
 }}}
 Reasoning is explained in `MkIface` where we convert a `DataCon` to a
 `ConDecl`
 {{{
           -- Tidy the univ_tvs of the data constructor to be identical
           -- to the tyConTyVars of the type constructor.  This means
           -- (a) we don't need to redundantly put them into the interface
 file
           -- (b) when pretty-printing an Iface data declaration in
 H98-style syntax,
           --     we know that the type variables will line up
           -- The latter (b) is important because we pretty-print type
 constructors
           -- by converting to IfaceSyn and pretty-printing that
           con_env1 = (fst tc_env1, mkVarEnv (zipEqual "ifaceConDecl"
 univ_tvs tc_tyvars))
                      -- A bit grimy, perhaps, but it's simple!
 }}}
 Meddling with `IfaceConDecl` is not a big deal... it's just a
 serialisation format, and changes are very localised. So feel free to
 suggest what to do.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13848#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler