[Haskell-cafe] RE: Modelling Java Interfaces with Existential data types

[Mike Aizatsky]

Ralf,

> thanks for your time to look into the HList paper.

It's quite good. It reminds me the quirks Alexandrescu does in his "Modern
C++ Design" or here
http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html .
Since type system allows implementation of natural arithmetic, do you know,
is it Turing-complete?

> I don't think that anything was required to be explicit:
> 
> If you mean this here:
> 
> type MyList =  MyImplementation1
>            :*: MyImplementation2
>            :*: HNil
> 
> ... then note that this type is inferred!

But I still would like to write type signatures for methods, operating with
HLists. Or should I make all my list processing functions to be classes
(like hfold) and to add type constraints in class definition? This sounds
like a serious development overhead for me.

> (i) I like comparing Haskell datatypes with Java classes.

But Java classes also contain t methods. What would you call methods in
Haskell? Functions on datatypes?

> (ii) In Haskell, when you want to say that you have different
> implementations for the same interface, or when you want to say
> that different datatypes provide implementations of a certain
> interface, then you use Haskell's type class system.

That's exactly my case.

> (v) When you define the methods of the
> interface to be implemented in Java, you define the methods of
> the instance. I would claim the Haskell code ends up being more
> modular :-)

It's the same level of module separation. But Haskell lead to a problem with
storing the different data - i.e. implementing Java polymorphism. You end up
with creating quite a complicate and non-trivial library for just
implementing something like List<Interface>.

> And our lovely HLists are
> just good for that, but they come with the added value that they
> don't make the elements opaque as it is the case with the sometimes
> troublesome existentials.

They indeed solve the problem, but at a great price of processing code
complication.

> > 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?).
> 
> Data.Dynamics

I don't see a way to store functions in a file. That's the task Clean
Dynamics solve.

> -- Yet another heterogeneous equality
> yaHEq :: (Typeable a, Typeable b, Eq a)  => a -> b -> Bool
> yaHEq a b = case cast b of
>              Just a' -> a == a'
>              Nothing -> False

Cool! Do you know anything about cast performance?

> I revise your existential wrapper type to include all goodies that are
> needed, say Eq and Typeable:

Works pretty well. Thanks a lot. I will definitely try to make a template
generator for any interfaces.

The only issue is to get rid of AnyMyInterface around the code. Can you
explain me why 

type MyList = forall a. (MyInterface a) => [a]
list1 :: MyList
list1 = [MyImplementation1 10, MyImplementation2 20]

doesn't work? Ghc gives pretty obscure (for me) error message:

    Cannot unify the type-signature variable `a'
        with the type `MyImplementation1'
        Expected type: a
        Inferred type: MyImplementation1
    In the application `MyImplementation1 10'
    In the list element: MyImplementation1 10

PS The sample in your previous post doesn't run due to lack of hMapOut

Regards,
Mike