
#15318: Core Lint error involving newtype family instances with wrappers -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4902 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, Phab:D4902 will fix the bug, but it perpetuates a mistake! Consider {{{ data family S a data family T a data instance S [a] = MkS a newtype instance T [a] = MkT a }}} Currently, we get this: {{{ data SList a = MkS a axiom coS a :: SList a ~ S [a] -- Wrapper for MkS $WMkS :: a -> S [a] $WMkS x = MkS x |> coS a -- newtype TList a = MkT a axiom coTList a :: a ~ TList a axiom coT a :: TList a ~ T [a] -- Worker for MkT MkT :: a -> T [a] MkT x = x |> coTList a |> coT a }}} Notice the inconsistency: the cast that takes us from the representation type to the final user type is done in the ''wrapper'' for data types, but in the ''worker'' for a newtype. (Reminder: for data types the worker isn't an executable function, it's the Core data constructor; but for a newtype the "worker" is an executable function that expands to a cast.) This inconsistency shows up in the `MkId` functions `wrapNewTypeBody` and `unwrapNewTypeBody`. The former wraps two casts (as above) while the latter unwraps only one! I think we can readily remove the inconsistency: * Don't export `wrapNewTypeBody` from `MkId`; it is not used outside. * Remove the extra cast from `wrapNewTypeBody` * Do not make the change to `mkDataConRep` proposed in Phab:D4902. * Make a wrapper for family-instance newtypes. Do this by making `wwrapper_reqd` return `True` for ''all'' types for which `isFamInstTyCon` holds. (Currently that predicate is not tested for newtypes.) I think that might be it. It solves the problem at source, produces less code and less to explain (because it's consistent). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15318#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler