"Simon Marlow"
Hmm, I deliberately didn't suggest using a type class. Do you really want to expose Win32 paths and POSIX paths, and whatever else, as different types? Maybe you do for extensibility, but you really want a single Path type too - otherwise portable code will have to use conditional compilation.
Good point. Ideally, you want to be able to write all FilePath code polymorphically at type (Path p => p), and have a decent defaulting mechanism available to choose a particular instance at compile time (perhaps conditionally, based on OS platform). Sadly, in the absence of a better 'default' declaration semantics, we are left having to resolve the ambiguity ourselves, or resort to some other type-system extension, like as you say existentials.
The Path type therefore has to be an existential wrapper:
data Path = (CPath p) => Path p
Maybe we do want to do this, but it causes portability issues with the Path library itself: nhc98 can't compile this code for example
Actually, nhc98 /can/ cope with existentials when written as: data Path = forall p . (CPath p) => Path p but it doesn't do local universal quantification like: data Path = Path (forall p . p) Regards, Malcolm