Patrick Browne :

I was checking out a paper that said: "Type classes allow for partial inheritance, so that penguins can be birds without flying behavior." ... as pointed out by Jerzy my question is silly because can penguins can fly ...

No, the question is not silly because of that crazy Adelie tribe. The question is doubtful, because the Haskell type classes is not an object-oriented system of classes, subclasses, etc. When you declare Rationals, you don't "inherit" the multiplication for them as Numbers. This "inheritance" you wish may manifest itself when you specify the *instances*. That's why I suggested how you might do that: for some datatypes, say the Emperors, you specify some special flying method (e.g. dummy or bombing), or you don't specify it at all. And the Emperors won't fly. Jerzy Karczmarczuk

Oh, I got it: You want to have: class Bird b where class Penguin p where instance (Penguin b) => Bird b where fly = -- fly method for penguins 2011/7/19 Patrick Browne

On 18/07/2011 19:14, Jerzy Karczmarczuk wrote:

...

That's why I suggested how you might do that: for some datatypes, say the Emperors, you specify some special flying method (e.g. dummy or bombing), or you don't specify it at all. And the Emperors won't fly.

-- Here is my attempt data Emperor = Emperor data Robin = Robin

class Bird a where fly :: a -> a -> a walk :: a -> a -> a

instance Bird Robin where fly x y = y walk x y = x

instance Bird Emperor where -- No fly method walk x y = y

class (Bird a) => Penguin a where -- I do not think that I can override the walk method in the sub-class -- must be done in instance of Penguin

instance Penguin Emperor where -- How can I override the walk method in the instance Penguin? -- walk x y = x

Regards, Pat

This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I haven't followed the thread carefully but why does the bird have to be a penguin?

A bird doesn't have to be a penguin : *instance* (Penguin b) => Bird b where fly = -- fly method for penguins Says that every Penguin is a Bird. But thinking back about it, there is a problem when trying to define the method walk, because: class Penguin p where walkPenguin :: .... instance (Penguin b) => Bird b where fly = ..... walk = walkPenguin is kind of awful, because walk has to be duplicated. So, not the best way to go... 2011/7/19 Maciej Marcin Piechotka

On Tue, 2011-07-19 at 01:13 +0200, Yves Parès wrote:

...

Oh, I got it: You want to have:

class Bird b where

class Penguin p where

instance (Penguin b) => Bird b where fly = -- fly method for penguins

I haven't followed the thread carefully but why does the bird have to be a penguin?

----------

As a side note - I agree with Christopher Done that the answer is that you shouldn't require for bird to fly.

Regards

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 19/07/2011, at 11:09 AM, Patrick Browne wrote:

data Emperor = Emperor data Robin = Robin

class Bird a where fly :: a -> a -> a walk :: a -> a -> a

instance Bird Robin where fly x y = y walk x y = x

instance Bird Emperor where -- No fly method walk x y = y

Note that "no 'fly' method is visibly presented" is not at all the same thing as "no 'fly' method EXISTS". From the report: "The default class method for v sub i is used if no binding for it is given in a particular instance declaration (see Section 4.3.2)." so the absence of a method in 'instance Bird Emperor' doesn't mean that it doesn't _have_ one, just that it inherits the default class method.

On Mon, Jul 18, 2011 at 3:14 PM, Jerzy Karczmarczuk wrote:

That's why I suggested how you might do that: for some datatypes, say the Emperors, you specify some special flying method (e.g. dummy or bombing), or you don't specify it at all. And the Emperors won't fly.

Instead of flying, they'll throw exceptions around. =/ -- Felipe.

Quoth "Richard O'Keefe" , [ ... re Werner Kuhn "An Image-Schematic Account of Spatial Categories" ... ]

class BUILDING building where class BUILDING house => HOUSE house where any instance of HOUSE *will* have in its interface everything that any instance of BUILDING will.

But ... for those who might be overly influenced by a superficial similarity to OOP here ... the idea that the above relationship makes House a subclass of Building isn't really a natural way to look at it. It's true that a House instance will also "have in its interface everything that any instance of Building will", but only because the programmer is constrained to do that. To consider the whole outline: class Building building where ... specify the behavior of buildings here, if any class Building house => House house where ... specify additional behavior of houses here, if any data Shed = Shed "shed" instance Building Shed where ... define Building functions for Shed instance House Shed where ... define House functions for Shed The Building => House constraint doesn't add anything, it just checks that each instance of House also is an instance of Building. If you omit this constraint, everything will work the same - even the constraint will still be there, implicitly, albeit not at the same level. To me, it's somewhat misleading to use words like "inheritance" and "subclass" for the relationship between Building and House, unless there's some feature of the system I missed. Donn