[Haskell-cafe] RE: Modelling Java Interfaces with Existential data
mm-aa at yandex.ru
Wed Jun 9 13:29:48 EDT 2004
> 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
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
> > It
> >might be possible to load them via hs-plugins or to obtain using
> >similar to Clean Dynamics (btw, is there anything similar available for
I don't see a way to store functions in a file. That's the task Clean
> -- 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
More information about the Haskell-Cafe