[bitc-dev] Type Classes Versus Tedium

Richard Uhtenwoldt ru at river.org
Wed Aug 24 05:32:33 EDT 2005


I've just read all the posts on this list that mention type
classes in the Subject line.

The salient thing for me about the discussion so far is that the
only motivation explicitly given for turning to type classes was
to remove the tedium caused by introducing into the programmer's
awareness names like +i8 +i16 +i32 +i64 +u8 +u16 +u32 +u64 +f32
+f64 +f128

This sort of tedium-removal alone is IMO not _quite_ enough of a
motivation to justify the costs of adding type classes to a
language.

There are simpler ways of removing the tedium, and if
tedium-removal is the only motivation, then BitC should do
experiments on real BitC code to determine whether the simpler
ways are sufficient before resorting to type classes.

Certainly it is common to see things like

    (let ((+ +u64)
          (- -u64)
          (* *u64)
          (/ /u64) )
      (- (* a c) (* b d)) )

in well-written Scheme code.

But even a cursory look at BitC's type system suggests that BitC
programmers will come to value type classes for motivations other
than simple tedium-removal: namely, type classes make a useful
addition to a Haskell-like type system.

Specifically, type classes increase the usefulness of the rest of
the Haskell type system as a tool to help one understand code and
to help the programmer express his intention to other programmers
who are experienced with the type system.  E.g., a type
declaration in Haskell can be viewed as an assertion about code
that is checked by the compiler.

The way I imagine type classes help you when you use the type
system regularly to make assertions about your code is that the
tedium caused by a combinatorial explosion of names becomes much
worse than it was when you were faced with only +i8 +i16 +i32
+i64 +u8 +u16 +u32 +u64 +f32 +f64 +f128 so that having strong
tedium-reduction technology becomes a necessity.  

So, there is a way of looking at type classes in which
tedium-removal _is_ the purpose, after all!  Perhaps a better
statement of my position is that if you are faced with a
profusion of names like +i8 +i16 +i32 +i64 +u8 +u16 +u32 +u64
+f32 +f64 +f128, etc, caused by a profusion of machine-language
instructions, or of machine-language data types, that alone is
not enough of a reason to turn to type classes.

In summary, in my opinion, the question is whether you want a
Haskell-like type system to help make BitC programs more correct
and more secure.  If you do, then you probably want type classes,
too.

(I'm not competent to comment on the wisdom of adding type classes
to an ML-like type sytem.)


Since Dr Jones is responsible for most successful extensions to
type classes, it is only natural that it is a little hard
sometimes for him to see some of the disadvantages of type
classes.  I OTOH suffer from no such disability.  

Also, I learned Haskell recently enough that it is sometimes 
possible for me to remember what it is like to be new to Haskell
and to have surmounted particular learning hurdles. 

So, here's some of the costs type classes impose.

Type classes were for me one of the larger hurdles to learning
Haskell because they make GHC's type checker's error messages
much more opaque.

This hurdle came up very early: specifically, when I tried to
print some value other than a String or a Char and got back
an opaque message about ambiguous use of the type class Show.

Eventually of course I became experienced in gleaning diagnostic
information from these error messages.  Moreover, I developed the
habit of explicitly _undoing_ the (ad-hoc) polymorphism
introduced by type class and instance declarations, to make the
error messages more decipherable.

e.g., instead of using + in my program, I would define

+integer :: Integer -> Integer -> Integer
(+integer) = (+)

and use +integer.

(Actually, +integer is not a valid lexeme in Haskell but you get
the idea.)

Or I'd define

returnIO :: a -> IO a
returnIO = return

and use returnIO instead of return.

I have a second, less-important reason for advising against
type classes, having to do with compilation time, but I'll hold
it till there's indication that people want to hear it.



More information about the bitc-dev mailing list