[GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied

GHC ghc-devs at haskell.org
Sun Feb 21 17:58:52 UTC 2016


#11594: closed empty type families  fully applied get reduced lazily when in a
constraint tuple and fully applied
-------------------------------------+-------------------------------------
        Reporter:  carter            |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:  8.0.1
       Component:  Compiler (Type    |              Version:  7.10.2
  checker)                           |
      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 carter):

 I guess it could be viewed as a feature request.

 I need to play around with the 8.0 / master  a bit to have a clear sense
 of if TypeError alone suffices, but I DO think that from a user /
 usability perspective, the fact that we DO present the definition of
 TypeError as being an empty closed type family in GHC.TypeLits will be
 confusing for some users.

 I think either
    a) the documentation in
 http://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/base-4.9.0.0
 /GHC-TypeLits.html#g:4 (the GHC.TypeLits module) should be changed to
 clearly articulate that TypeError has special wired-in behavior that can't
 be replicated in userland, (including what special treatment it gets
 versus userland type families that are written simularly) OR

    b) anything that has a reasonable looking  source definition in base
 that isn't the infinite loop style found in
 http://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/ghc-
 prim-0.5.0.0/GHC-Prim.html and not explicitly documented as being a deeply
 magical / wired-in  behavior really should be replicable in userland


 zooming out: its probably the case that for me, TypeError will probably be
 fine for me, but my main concern is about having a clearer understanding
 of whats a magical special case and what isnt', and how the semantics of
 the pieces of magics is clearly articulated

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


More information about the ghc-tickets mailing list