Superclass Cycle via Associated Type

[Edward Kmett]

On Mon, Jul 25, 2011 at 4:46 AM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

>  On further reflection I have a question.****
>
> ** **
>
> Under the limited design below, which Edward says will do all he wants:***
> *
>
> **·         **The mutually recursive classes (call them A, B, C) must be
> defined all together. Like
>    class B a => A a;  class C a => B a;  class A a => C a****
>
> **·         **If a type T is an instance of any of those classes, it must
> be a member of all of them****
>
> **·         **If a function f has type f :: A a => blah, then the
> signature f :: B a => blah and f :: C a => blah would work equally well
>
> In short, I see no advantage to making A,B,C separate classes compared to
> simply unioning them into a single class.
>


> **
>
> Bottom line: adding recursive superclasses with the restrictions I describe
> below would add no useful expressive power.  But it would cost effort to
> implement. So why do it?****
>
> ** **
>
> Maybe I’m missing something.
>

In the univariate case this is true, but I think we've lost sight of the
original motivation.

In the MPTC case there is a real difference.

In my example (with methods),

If you have an associative (+), then you can use (.*) to multiply by a whole
number, I currently do fold a method into the Additive class to 'fake' a
LeftModule, but you have to explicitly use it.

class Additive m => LeftModule r m
class LeftModule Whole m => Additive m

This says that if you have an Additive semigroup, then there exists a
LeftModule over the whole numbers, and that every leftmodule is additive,
but there can exist other LeftModules than just ones over the whole
numbers!

Given LeftModule Integer m, you'd know you have Additive m and LeftModule
Whole m.

LeftModule Integer m => LeftModule Whole m <=> Additive m.

Balling them up together precludes the ability to use LeftModule to describe
the relationship of whole numbers to a semigroup.

But moreover it causes me to have to write code that would be parameterized
by the LeftModule in question 5 times, because I have to special case the
module structures over wholes, naturals, integers and the ring itself
relative to code for any other module.

There is a gain in expressive power, but you need multiple parameters to
exploit it.

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