Asserting vars with different Uniques represent the same Object
My core questions are: * Should variables representing the same thing always have the same unique? * If not how can one assert they actually represent the same thing? Working on the pattern matching code I came across this assertion:
ASSERT(tvs1 `equalLength` ex_tvs ) http://git.haskell.org/ghc.git/blob/HEAD:/compiler/deSugar/MatchCon.hs#l125
tvs1 and ex_tvs are both the existentially quantified type variables of a pattern. One gained by taking apart the pattern itself and one by taking apart the ConLike in the pattern. While as far as I can tell they always represent the same Types they don't always compare as equal. Is there any other stable way to compare them? (By name? Something else?). Or is them not being equal a bug to begin with. Follow up question: The whole assert is essentially a unit test as ex_tvs isn't used outside of the assert. Is there a solution to check these invariants in tests instead of the source code?
Andreas Klebinger
My core questions are:
* Should variables representing the same thing always have the same unique? * If not how can one assert they actually represent the same thing?
Working on the pattern matching code I came across this assertion:
ASSERT(tvs1 `equalLength` ex_tvs ) http://git.haskell.org/ghc.git/blob/HEAD:/compiler/deSugar/MatchCon.hs#l125
tvs1 and ex_tvs are both the existentially quantified type variables of a pattern. One gained by taking apart the pattern itself and one by taking apart the ConLike in the pattern.
Could you elaborate a bit more here? This sounds like a bug but I'm not sure I completely follow how you came about these tyvars.
Follow up question: The whole assert is essentially a unit test as ex_tvs isn't used outside of the assert. Is there a solution to check these invariants in tests instead of the source code?
If I understand the question correctly: no. GHC contains hundreds of assertions like this which are only enabled when the compiler is compiled with -DDEBUG. The advantage of including them in the source instead of an external test is that it keeps the invariant check right next to the implementation, where it belonds. Cheers, - Ben
participants (2)
-
Andreas Klebinger -
Ben Gamari