Superclass Cycle via Associated Type

Simon Peyton-Jones simonpj at microsoft.com
Mon Jul 25 10:46:03 CEST 2011


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.

Simon

From: Edward Kmett [mailto:ekmett at gmail.com]
Sent: 22 July 2011 20:07
To: Simon Peyton-Jones
Cc: Gábor Lehel; glasgow-haskell-users at haskell.org
Subject: Re: Superclass Cycle via Associated Type

2011/7/22 Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
I talked to Dimitrios.  Fundamentally we think we should be able to handle recursive superclasses, albeit we have a bit more work to do on the type inference engine first.

The situation we think we can handle ok is stuff like Edward wants (I've removed all the methods):

class LeftModule Whole m => Additive m
class Additive m => Abelian m
class (Semiring r, Additive m) => LeftModule r m
class Multiplicative m where (*) :: m -> m -> m
class LeftModule Natural m => Monoidal m
class (Abelian m, Multiplicative m, LeftModule m m) => Semiring m
class (LeftModule Integer m, Monoidal m) => Group m
class Multiplicative m => Unital m
class (Monoidal r, Unital r, Semiring r) => Rig r
class (Rig r, Group r) => Ring r
The superclasses are recursive but
 a) They constrain only type variables
 b) The variables in the superclass context are all
        mentioned in the head.  In class Q => C a b c
        fv(Q) is subset of {a,b,c}

Question to all: is that enough?

This would perfectly address all of the needs that I have had!

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


More information about the Glasgow-haskell-users mailing list