[GHC] #11715: Constraint vs *
GHC
ghc-devs at haskell.org
Tue Dec 6 18:57:10 UTC 2016
#11715: Constraint vs *
-------------------------------------+-------------------------------------
Reporter: bgamari | Owner:
Type: bug | Status: new
Priority: high | Milestone: 8.2.1
Component: Compiler (Type | Version: 8.0.1-rc1
checker) |
Resolution: | Keywords: Typeable
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 int-index):
I see a few problems with this approach:
1. `RuntimeRep` is used to distinguish things with different run-time
representations. I understand why it's sound if things represented equally
get different `RuntimeRep`s, but it's not what `RuntimeRep` is for, so
those fake inequalities are something to avoid (and you suggest to exploit
it). Of course I understand that I'm in no position to tell you what
`RuntimeRep` means because you invented it, but as a user I have certain
expectations and intuition about what it means, and the name suggests that
it means a run-time representation, not some arbitrary distinction which
turned out to be convenient! A leaky abstraction.
2. I do think that having `Constraint ~ *` is useful in user code, because
right now I have to use `Dict` to go from `Constraint` to `*` and `Given`
to go in the opposite direction. It is very inconvenient!
3. We don't get the safe implementation of `reflection` (without
`unsafeCoerce`) this way, do we? And if we stop encoding one-element
classes as newtypes, the current implementation of `reflection` will
break.
Making `Constraint` a synonym for `*` sounds very simple and elegant. What
are the reasons to pursue a more complicated solution? It seems to me that
all of the objections were addressed in this thread.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11715#comment:50>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list