Superclass Cycle via Associated Type

[Gábor Lehel]

2011/7/22 Dan Doel <dan.doel at gmail.com>:
> 2011/7/22 Gábor Lehel <illissius at 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.