So I believe the "final" way to do this, which is not yet implemented,
works something like this:
type family LeftToRight a
type family RightToLeft b
class (LeftToRight a ~ b, RightToLeft b ~ a) => Bijection a b where
...
I agree, the fact that this doesn't work is really dumb.
I used a slightly devious trick to solve this for Control.Coroutine[1]:
type family Dual a
-- what I wanted to write:
class (s ~ Dual (Dual s)) => Connect s where
connect :: Session s a -> Session (Dual s) b -> (a,b)
-- what I actually wrote
class Connect s where
connect :: (s ~ Dual (Dual s)) => Session s a -> Session (Dual s) b -> (a,b)
This was good enough to give the constraints I needed to implement
"connect" for each of the session operators.
-- ryan
[1] http://hackage.haskell.org/packages/archive/Coroutine/0.1.0.0/doc/html/Contr...
On Tue, Aug 3, 2010 at 10:25 AM, Andrew Coppin
OK, so if you do something like
class Container c where type Element c :: *
then we now have a clean and concise way to discover what type of element any given container holds. (Regardless of whether it's element type is parametric, hard-coded, class-constrained or anything else.) I really like this!
Now suppose that instead of a container type with an associated element type, what we want is several pairs of types having a one-to-one relationship, and we want to be able to traverse that relationship in either direction. What's the best way to do that?
(I tried just having two mirror image classes like the one above. But that doesn't work; there's no guarantee that going one way and then going back the other way will definitely take you back to where you started. I tried to make that a constraint, and got an error message that basically says "this feature is not implemented". Great. Still, there's probably a better way to do this.)
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe