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 _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
