2011/7/22 Dan Doel <dan.d...@gmail.com>: > 2011/7/22 Gábor Lehel <illiss...@gmail.com>: >> Yeah, this is pretty much what I ended up doing. As I said, I don't >> think I lose anything in expressiveness by going the MPTC route, I >> just think the two separate but linked classes way reads better. So >> it's just a "would be nice" thing. Do recursive equality superclasses >> make sense / would they be within the realm of the possible to >> implement? > > Those equality superclasses are not recursive in the same way, as far > as I can tell. The specifications for classes require that there is no > chain: > > C ... => D ... => E ... => ... => C ... > > However, your example just had (~) as a context for C, but C is not > required by (~). And the families involved make no reference to C, > either. A fully desugared version looks like: > > type family Frozen a :: * > type family Thawed a :: * > > class (..., Thawed (Frozen t) ~ t) => Mutable t where ... > > I think this will be handled if you use a version where equality > superclasses are allowed.
To be completely explicit, I had: class (Immutable (Frozen t), Thawed (Frozen t) ~ t) => Mutable t where type Frozen t ... class (Mutable (Thawed t), Frozen (Thawed t) ~ t) => Immutable t where type Thawed t ... When I last tried this in the 7.0 time frame (before it was discovered that equality superclasses don't actually work yet and got disabled), it gave me a superclass cycle error for the first halves of those contexts, and for the second halves (the equality constraints) I believe it caused some kind of context stack depth to be exceeded (again because of the recursiveness). I'll have to try this again once I manage to get 7.2 compiled. > > -- Dan > -- Work is punishment for failing to procrastinate effectively. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users