= Class Aliases = This is a proposal for a language extension which will hopefully mitigate the issues holding back evolution of the standard prelude as well as provide useful class abstraction capabilities in general. It's main goals are to * remove the false tension between the granularity of a class hierarchy and its practical usability. * Allow one to modify a class hierarchy while retaining 100% backwards compatibility with a class API. with a specific use being able to replace the prelude's numeric hierarchy while retaining full haskell 98 compatibility, including the fact that libraries that only know about haskell 98 will have their instances automatically propagated to the new class hierarchy (and vice versa), so switching over can be fully incremental. * allow one to provide simple and advanced interfaces to a class hierarchy, much as one can do with function libraries. * it incidentally allows certain things that have been requested on the list as 'nice to have' but not world shattering. * not interfere with separate compilation and be describable by a straightforward source->source translation. feel free to skip the next section if you know the issues involved in replacing the numeric hierarchy of the prelude transparently :) This specification is meant to be informal but precise and complete. if any of the translation rules are unclear, then let me know. == The Problem == Many alternate preludes have been proposed, however to date none have gained popularity beyond the extensions to the standard libraries provided by fptools. Since as a general rule, the haskell community only likes to standardize changes that have been actively used and implemented already (a very good policy) this makes evolution of the standard problematic. Although it is easy enough to provide new functions and datatypes, providing wrapper routines with the old interfaces to allow incremental use of a new prelude or any library. there is no way to hide the fact that you changed a class hierarchy. if you split a class into two, every instance has to change, even if the split is irrelevant to a given datatype. Furthermore, depending on how you split or join classes, many type signatures will have to be rewritten. Since Haskell projects tend to be amalgamations of many different libraries and code from previous projects, this makes using alternate preludes with anything larger than a toy project unpossible. The problem is compounded when you consider the fact that we ideally want multiple competing preludes or certainly different versions of the same one. Imagine a library that provides a handy new Numeric datatype. the writer of the library only knows about the main prelude and doesn't concern himself with the various experimental preludes out there so declares an instance for Num. Bill comes along and realizes he needs an instance for the new Prelude so declares it an instance of ExperimentalNum, Phil, who also uses the library and the new experimental prelude needs to declare his own ExperimentalNum instance. suddenly Bill's and Phil's libraries cannot be combined by Susan who just wants to get work done and needs both Bill's and Phil's libraries. The basic issue is that you end up with a quadratic number of instances for every datatype combined with every alternative prelude and it is not clear who should be providing these instances. every library writer should not need to know about every alternate prelude out there and vice versa. Not only that but most of the instances will be very redundant, ExperimentalNum and Num most likely provide many of the same operations, you should only need to declare an instance for one and have it automatically propegated to the other. == The Extension == In haskell, you may create abstract data types, where you are free to change the internal representation without affecting the visible interface, you may create function impedance matching libraries, providing alternate interfaces to the same functionality. however, there is no way to abstract your class hiearchy. there is no way to hide your class layout in such a way you can change it behind the scenes, once a sizable codebase is built up expecting a certain class layout, there is no incremental migration path to something better. This extension allows the creation of class aliases, or effectively different views of the class hierarchy. this allows library writers to change the class hierarchy under the hood without affecting the visible interface as well as providing cleaner interfaces to begin with, hiding unimportant implementation details of how the classes are laid out from regular users, while providing the more advanced interfaces to power users. This extension may be carried out completely in the front end via a source->source translation and does not inhibit separate compilation. given

class Foo a where foo :: a -> Bool foo x = False

class Bar b where bar :: Int -> b -> [b]

We allow new constructs of this form (the exact syntax is flexible of course):

class alias (Foo a, Bar a) => FooBar a where foo = ...

what this does is declare 'FooBar a' as an alias for the two constraints 'Foo a' and 'Bar a'. This affects two things. FooBar a may appear anywhere a class constraint may appear otherwise, it's meaning is simply (Foo a, Bar a) and the expansion may be carried out as a simple macro replacement, like type synonyms. The other thing is that one may declare instances of FooBar.

instance FooBar Int where foo x = x > 0 bar n x = replicate n x

this expands to:

instance Foo Int where foo x = x > 0

instance Bar Int where bar n x = replicate n x

The meaning of declaring a type an instance of a class alias is that it declares the type an instance of each class that makes up the alias, distributing the method definitions to their respective classes, using the default methods declared in the class alias if available, otherwise using the default methods of the underlying class. This also may be carried out as a simple translation in the front end. let us look at a more concrete example: the current Num class in the Prelude is (more or less) this

class Num a where (+), (*) :: a -> a -> a (-) :: a -> a -> a negate :: a -> a fromInteger :: Integer -> a

ideally we would want to split it up like so (but with more mathematically precise names):

class Additive a where (+) :: a -> a -> a zero :: a

class Additive a => AdditiveNegation where (-) :: a -> a -> a negate :: a -> a x - y = x + negate y

class Multiplicative a where (*) :: a -> a -> a one :: a

class FromInteger a where fromInteger :: Integer -> a

now this presents some problems: * people using the new prelude have to write the ungainly (FromInteger a, AdditiveNegation a, Multiplicative a) and declare separate instances for all of them. * if at some point a HasZero class is separated out then everyone needs to modify their instance declarations. * Num still must be declared if you want it to work with old prelude functions, containing completely redundant information. * all the problems mentioned in the second section above about alternate preludes in general. these can be solved with the changing of Num into a class alias.

class alias (Addititive a, AdditiveNegation a, Multiplicative a, FromInteger a) => Num a where one = fromInteger 1 zero = fromInteger 0 negate x = zero - x

now, all of the above problems are solved. You may use the short 'Num a' notation for numbers, if a HasZero class is split out then it doesn't matter because declaring something a (Num a) will propagate your methods to it properly. declaration of an instance for Num will automatically create instances for all the other classes, declaring separate instances for each of the other classes will give you the equivalent of an instance for Num. people writing libraries need not concern themselves with the alternate prelude or the haskell 98 one, they can pretend the other doesn't exist and their instance declarations will automatically create appropriate instances in the alternate prelude. == Another Example == This example is unrelated to creating an alternate prelude but shows how this extension is a useful abstraction tool in general. imagine we want to create a great lattice class library. I mean, a super really flexible one.

class Lattice a where meet :: a -> a -> a join :: a -> a -> a

of course, you want to be able to express lattices with a distinguished top and bottom.

class Lattice a => BoundedLattice a where top :: a bottom :: a meets :: [a] -> a joins :: [a] -> a meets xs = foldl meet top xs joins xs = foldl join bottom xs

hmm.. but then you realize you might want semi lattices.. so you change it too

class SemiLatticeMeet a where meet :: a -> a -> a

class SemiLatticeJoin a where join :: a -> a -> a

class (SemiLatticeMeet a,SemiLatticeJoin a) => BoundedLattice a where top :: a bottom :: a meets :: [a] -> a joins :: [a] -> a meets xs = foldl meet top xs joins xs = foldl join bottom xs

but then you realize you might want bounded semilattices so you come up with the following. your final super flexible lattice class.

class BoundedAbove a where top :: a

class BoundedBelow a where bottom :: a

class SemiLatticeMeet a where meet :: a -> a -> a

class SemiLatticeJoin a where join :: a -> a -> a

meets :: (BoundedAbove a,SemiLatticeMeet a) => [a] -> a meets xs = foldl meet top xs

joins :: (BoundedBelow a,SemiLatticeJoin a) => [a] -> a joins xs = foldl join bottom xs

notice two things beyond the points mentioned above: 1. You have pissed off all your users... they just wanted to declare a simple bounded lattice and now they have to type a whole lot of crud to do so. refer to the docs several times to see how you named things and know some non-trivial things about lattices. 2. creating a simple bounded lattice instance for Bool requires writing 4 instances, none of which actually say 'BoundedLattice'! not very intuitive or flexible. 3. you can no longer make meets and joins members of a type class, meaning you cannot create optimized versions of them for certain types which most definitely exist and are important for many applications of lattices. you have traded flexibility in one direction for flexibility in another. of course, you could do something like

class (BoundedBelow a, SemiLatticeJoin a) => BoundedBelowJoinable a where joins :: [a] -> a

but things are already getting absurd. no user is going to type BoundedBelowJoinable constantly when they just want a lattice. there is a fundamental weakness in haskell here in that it creates a false tension between these two types of flexibility, this is compounded by the inability to change type classes without changing your interface so it is hard to tweak things if it turns out you chose something non-ideally. now, lets look at the above with class aliases.

class SemiLatticeMeet a where meet :: a -> a -> a

class SemiLatticeJoin a where join :: a -> a -> a

class alias (SemiLatticeMeet a, SemiLatticeJoin a) => Lattice a

class BoundedAbove a where top :: a

class BoundedBelow a where bottom :: a

class alias (BoundedAbove a, BoundedBelow a) => Bounded a

class (BoundedBelow a, SemiLatticeJoin a) => BoundedBelowJoinable a where joins :: [a] -> a joins xs = foldl join bottom xs

class (BoundedAbove a, SemiLatticeMeet a) => BoundedAboveMeetable a where meets :: [a] -> a meets xs = foldl meet top xs

class alias (BoundedBelow a, BoundedAbove a, SemiLatticeMeet a, SemiLatticeJoin a,BoundedBelowJoinable a, BoundedAboveJoinable b) => BoundedLattice a

this looks complicated but you really wanted to write a super-ultra fancy lattice class. But from a library users point of view it is great: The library user simply need to declare

instance BoundedLattice Bool where top = True bottom = False meet = (&&) join = (||)

and _all_ of the above classes are filled in properly. someone else can write

instance Lattice Integer where join = max meet = min

while a power user is free to declare his SemiLattices or BoundedAboveMeetables or whatever. this is a great benefit IMHO. There has always been a false tension between the granularity of your class hierarchy and its practical usability. this extension gets rid of that tension. == Notes == * class aliases are also able to introduce new superclass constraints, such as in the Num example we also want to enforce a (Eq a, Show a) superclass constraint. the interpretation is straightforward, Num in type signatures expands as if those were part of the alias and when declaring instances the existence of instances for the superclasses are checked, but not filled in automatically. I didn't show an example so as to not confuse the basic idea and because I have not come up with a syntax I am happy with. (suggestions welcome) * How these interact with other type class extensions would have to be figured out. it shouldn't present an issue and I think even if class aliases needed to be restricted to single parameter type classes (unlikely) then they would still be useful. * deciding what to display in error messages is an issue. but no more complicated than deciding whether to show a type synonym or an underlying type. a heuristic like show the most general constraint that can be expressed with the names in scope should suffice. * although it is basically a source->source translation, in practice it could not be carried out by a preprocessor because all the names needed would not be in scope and we would want to propagate the class alias information in the 'hi' files (or equivalent) of the compiler. * I had an earlier supertyping proposal you might know about, I feel this is a much better proposal even though it doesn't fully subsume my supertyping proposal, I feel it solves the problems it was meant to solve in a cleaner and easier to implement way. * You may wonder why for the num example I put Additive a in the class alias even though it was already a superclass of AdditiveNegation. that is because class aliases do not change the meaning of superclasses, you need to explicitly list a class if you want instance declarations to propagate methods to it. superclasses are checked just like normal in class aliases. * incidental but not earth-shattering benefits include being able to declare an instance for a class and all its superclasses at once, smarter defaults when you are combining related classes, and much nicer type signatures by being able to create your own aliases for common combinations of classes. -- John Meacham - ⑆repetae.net⑆john⑈