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