Quoth "Richard O'Keefe"
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