Take a look around you. Haskell provides several sorts of container. We
have:
Data.List
Data.Set
Data.Map
Data.Hashtable
Data.ByteString
Data.Sequence
Data.Array
Data.Tree
Data.IntSet
Data.IntMap
...
In other words, we have *a lot* of different data containers. And yet,
each one provides its own unique API.
To anybody used to OO languages, that sounds pretty crazy. In something
like Java or Smalltalk or Eiffel, you have an abstract class that
represents "container", and maybe a seperate one for "ordered
container", and then concrete subclasses for each kind of container.
Each one may add a few unique methods of its own, but basically all the
containers have a uniform API, and you can write functions that work for
any arbitrary [ordered] container.
In Haskell, you can't do this. Why is that?
To me, it seems that there are two sticking points:
1. Historical reasons.
2. The Haskell '98 type system.
(1) is obviously solvable. (2) is harder.
Some containers can contain *any* type of data. Haskell permits
parametric polymorphism, so this is no problem:
Data.List.map :: (a -> b) -> [a] -> [b]
Other containers only support *one* type of data:
Data.ByteString.Char8.map :: (Char -> Char) -> ByteString -> ByteString
The type has a different kind, and the function parameter's type is more
constrained. Yet still this poses no problem.
However... now try writing a class that both of these functions could be
methods of. Good luck with that, by the way...
This is AFAIK also the reason why, e.g., Set is *not* an instance of
Monad; you can't write a valid instance. The type checker won't have it.
To ears accustomed to the OO way, all this makes it sound like Haskell's
type system sucks. (Which is rich, because in half the OO languages, you
can't write a type-safe container that works for arbitrary element types
in the first place! Haskell is a Big Win here.)
If I understand this correctly, to solve this problem you need either
Functional Dependencies or Associated Types. Is that correct?
I also gather that "FDs have problems" - although I have no idea what
those problems are. Everybody's hoping that ATs will fix this, but ATs
are still kinda new. (Are they even fully implemented in GHC yet?)
Can anybody correct/expand on this state of affires? I just want to make
sure I understand our position correctly...
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
