[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