<div class="gmail_quote">2011/7/25 Gábor Lehel <span dir="ltr"><<a href="mailto:illissius@gmail.com">illissius@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="h5">> type family Frozen t<br>
> type family Thawed t<br>
> class Immutable (Frozen t) => Mutable t where<br>
> thawedFrozen :: t -> Thawed (Frozen t)<br>
> unthawedFrozen :: Thawed (Frozen t) -> t<br>
><br>
> class Mutable (Thawed t) => Immutable t where<br>
> frozenThawed :: t -> Frozen (Thawed t)<br>
> unfrozenThawed :: Frozen (Thawed t) -> t<br>
><br>
> would enable you to explicitly program with the two isomorphisms, while<br>
> avoiding superclass constraints.<br>
<br>
</div></div>Hmm, that's an interesting thought. If I'm guesstimating correctly,<br>
defining instances would be more cumbersome than with the MPTC method,<br>
but using them would be nicer, provided I write helper functions to<br>
hide the use of the isomorphism witnesses. I'll give it a try. Thanks!<br>
<br>
I seem to recall that in one of your packages, you had a typeclass<br>
method returning a GADT wrapping the evidence for the equality of two<br>
types, as a workaround for the lack of superclass equality constraints<br>
-- what makes you prefer that workaround in one case and this one in<br>
another?</blockquote><div><br></div><div>In a very early version of representable-tries I used my eq package to provide equality witnesses:</div><div><br></div><div><a href="http://hackage.haskell.org/packages/archive/eq/0.3.3/doc/html/Data-Eq-Type.html">http://hackage.haskell.org/packages/archive/eq/0.3.3/doc/html/Data-Eq-Type.html</a></div>
<div><br></div><div>But I've turned in general to using explicit isomorphisms for things like </div><div><br></div><div><a href="http://hackage.haskell.org/packages/archive/representable-tries/2.0/doc/html/Data-Functor-Representable-Trie.html">http://hackage.haskell.org/packages/archive/representable-tries/2.0/doc/html/Data-Functor-Representable-Trie.html</a></div>
<div><br></div><div>because they let me define additional instances that are isomorphic to old instances quickly, while an actual equality witness would require me to bang out a new representation and all 20+ superclass instances. This enables me to write instances for thin newtype wrappers like those in Data.Monoid, etc. that I would be forced to just skip in a heavier encoding.</div>
<div><br></div><div>-Edward</div></div>