Modelling Java Interfaces with Existential data types

[Mike Aizatsky]

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