At 00:59 03/05/2003 -0700, Ashley Yakeley wrote:
In article <5.1.0.14.2.20030501153714.00b77c40@127.0.0.1>, Graham Klyne <gk@ninebynine.org> wrote:
It appears that it is not possible for a subclass to define a default for one of its superclass functions.
Correct. This is a common desire I think especially among people used to OOP, but there doesn't seem to be a clean way of doing it.
FWIW, I can live with this OK, using the device I mentioned previously. But I thought I might be missing something, which, in a sense, I was...
For instance:
module M where
class C a where foo :: a -> a
class (C a) => D a where foo = id
instance C Char
module N where import M
instance D Char
When compiling M, the compiler doesn't know instance D Char, so would presumably complain (warning) that foo is not defined in C and give it an undefined default.
Perhaps it could work if it were a condition that instances of C and D be defined in the same module, and also if missing members in instances were errors rather than warnings (a good idea anyway IMO).
... I hadn't fully appreciated that an instance declaration without a corresponding function definition would be OK. But maybe there's still a problem if one allows inheritance of function definitions: if the "instance C Char" indeed had a definition of "foo", then the definition of "foo :: Char -> Char" could vary in unexpected ways depending on which modules were imported? So, on reflection, it seems we have that being able to declare an *existing* data type as an instance (as opposed to OO style with static typing, where one typically must declare a new datatype to inherit from a supertype, I think), inheriting default definitions from a superclass can create undesired sensitivity to the visibility of module definitions. #g ------------------- Graham Klyne <GK@NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E