Superclass Cycle via Associated Type

Edward Kmett ekmett at gmail.com
Mon Jul 25 16:09:39 CEST 2011


2011/7/25 Gábor Lehel <illissius at gmail.com>

> > type family Frozen t
> > type family Thawed t
> > class Immutable (Frozen t) => Mutable t where
> >   thawedFrozen :: t -> Thawed (Frozen t)
> >   unthawedFrozen :: Thawed (Frozen t) -> t
> >
> > class Mutable (Thawed t) => Immutable t where
> >   frozenThawed :: t -> Frozen (Thawed t)
> >   unfrozenThawed :: Frozen (Thawed t) -> t
> >
> > would enable you to explicitly program with the two isomorphisms, while
> > avoiding superclass constraints.
>
> Hmm, that's an interesting thought. If I'm guesstimating correctly,
> defining instances would be more cumbersome than with the MPTC method,
> but using them would be nicer, provided I write helper functions to
> hide the use of the isomorphism witnesses. I'll give it a try. Thanks!
>
> I seem to recall that in one of your packages, you had a typeclass
> method returning a GADT wrapping the evidence for the equality of two
> types, as a workaround for the lack of superclass equality constraints
> -- what makes you prefer that workaround in one case and this one in
> another?


In a very early version of representable-tries I used my eq package to
provide equality witnesses:

http://hackage.haskell.org/packages/archive/eq/0.3.3/doc/html/Data-Eq-Type.html

But I've turned in general to using explicit isomorphisms for things like

http://hackage.haskell.org/packages/archive/representable-tries/2.0/doc/html/Data-Functor-Representable-Trie.html

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.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20110725/833fc106/attachment.htm>


More information about the Glasgow-haskell-users mailing list