[Haskell-cafe] closed classes [was: Re: exceptions vs. Either]

Duncan Coutts duncan.coutts at worcester.oxford.ac.uk
Fri Aug 6 10:10:39 EDT 2004

On Fri, 2004-08-06 at 14:05, MR K P SCHUPKE wrote:
> >You should include the definitions of the classes before saying
> HOrderedList l' just has to prove by induction that for any element
> in the list, the next element is greater, so the class is simply:
> class HOrderedList l
> instance HNil
> instance HCons a HNil
> instance (HOrderedList (HCons b l),HLe a b) => HCons a (HCons b l)

Somewhat off-topic,

It's when we write classes like these that closed classes would be
really useful.

You really don't want people to add extra instances to this class, it'd
really mess up your proofs!

I come across this occasionally, like when modelling external type
systems. For example the Win32 registry or GConf have a simple type
system, you can store a fixed number of different primitive types and in
the case of GConf, pairs and lists of these primitive types. This can be
modelled with a couple type classes and a bunch of instances. However
this type system is not extensible so it'd be nice if code outside the
defining module could not interfere with it.

The class being closed might also allow fewer dictionaries and so better
run time performance.

It would also have an effect on overlapping instances. In my GConf
example you can in particular store Strings and lists of any primitive
type. But now these two overlap because a String is a list. However
these don't really overlap because Char is not one of the primitive
types so we could never get instances of String in two different ways.
But because the class is open the compiler can't see that, someone could
always add an instance for Char in another module. If the class were
closed they couldn't and the compiler could look at all the instances in
deciding if any of them overlap.

So here's my wishlist item:

closed class GConfValue v where


More information about the Haskell-Cafe mailing list