Ralf, I've read the paper (surprisingly it's quite new - Jun 2004) and your sample. Here are several comments: 1. It looks like your HList is basically a "sugarized" version of data AnyMyInterface = Impl1 MyImplementation1 | Impl2 MyImplementation2 with the same drawback: you require me to explicitly list all the possible implementations of my interface, while the existential version of AnyMyInterface accepts all the implementation, whenever they came from. It might be possible to load them via hs-plugins or to obtain using something similar to Clean Dynamics (btw, is there anything similar available for Haskell?). 2. There will also be problems in gluing the utility/legacy code. E. g. if I want to call any list function on HLists (e.g. reverse). The idea of having heterogeneous FiniteMap can be implemented by storing the single-element lists, but it will complicate the code, which will work with the map. 3.
Your quality can indeed not work because the existentially quantified implementations are of course opaque. You can just compare apples and oranges.
Why? The idea of equality testing (not comparing) seems to be easily applies to apples and oranges. Is an Apple equal to an Orange? No. Is big Apple equal to small Orange? No. Is small Apple equal to small Apple? Yes. (The exact answer depends on the application). I'm completely confident with applying (==) to different type. It's quite a common operation in OO-world. I would like to have the following behaviour: instance Eq AnyMyInterface where (==) (AnyMyInterface a1) (AnyMyInterface a2) = if (typeOf a1) == (typeOf a2) then false else a1 == a2