Re: Modelling Java Interfaces with Existential data types
Hi Mike, Let's redirect to Haskell cafe. http://www.mail-archive.com/glasgow-haskell-users%40haskell.org/msg06288.htm... http://www.mail-archive.com/glasgow-haskell-users%40haskell.org/msg06289.htm... thanks for your time to look into the HList paper.
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
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! So with HLists, there is nothing like your Impl1 and Impl2, and no new datatype like your AnyMyInterface. Just for clarity: (i) I like comparing Haskell datatypes with Java classes. (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. (iii) When you define an interface in Java, you rather define a type class in Haskell. Type class are of course more powerful, but we don't mind. (iv) When you say "implements" in Java, you rather say "instance" in Haskell. (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 :-) You immediately get a simple form of Java-like interface polymorphism in Haskell, say when you got a constraint, then you are polymorphic over implementations (instances) of that constraint. The crux of your concern seems to be that you want to package values of different types (Java: classes). Indeed you want to have heterogeneous containers modulo subtyping. 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.
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 Not needed here.
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.
I concur. Using HList for everything is perhaps too invasive. The HList paper makes clear that there are certain cases where HLists are really needed, and they are complementary what generics provide you with in Java. I was just able to use them for something were a Generic Java programmer uses Generics and subtyping for. So existentials are perhaps Ok. However, directly comparing the opaque values is untypeable,
I'm completely confident with applying (==) to different type. It's quite a common operation in OO-world.
Yes, what you need is type-safe cast. See paper 1 here: http://www.cs.vu.nl/boilerplate/
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
Java is just a weakly typed subset of Haskell :-) Here we go ... -- 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 *Main> yaHEq True True True *Main> yaHEq True "True" False *Main> As you said yesterday that the equality issue is your main problem, let's wipe this out for existentials as well. I revise your existential wrapper type to include all goodies that are needed, say Eq and Typeable: data AnyMyInterface = forall a. ( Eq a , Typeable a , MyInterface a ) => AnyMyInterface a This is just your list type: type MyList' = [AnyMyInterface] Here are two lists: list4 = [ AnyMyInterface $ MyImplementation1 10 , AnyMyInterface $ MyImplementation1 10 ] list5 = [ AnyMyInterface $ MyImplementation1 10 , AnyMyInterface $ MyImplementation2 10 ] Here is a demo: *Main> list4!!0 == list4!!1 True *Main> list5!!0 == list5!!1 False Cheers, Ralf PS1: All code is here: http://homepages.cwi.nl/~ralf/HList/code.html PS2: I guess Sheard's work on parameterised modules might also interest you. http://portal.acm.org/citation.cfm?id=507648&dl=ACM&coll=portal And John Huges Restricted Data types as it shows how to reify dictionaries:
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
Mike Aizatsky wrote:
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?
Yes, C. McBride and T. Hallgren and others have done earlier examples of what they or we call faked dependently programming or type-level programming. It is not just Turing complete, it is phantastic. By using type equality and other goodies, we got pretty far.
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.
Yes, we favour a dedicated class per method. Everything beyond that is future work / current research. Agreed: faking is faking. We want better support for this style.
(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?
Java's methods end up in Haskell as methods in the type classes. Clearly, the data part can still comprise higher-order functions. BTW: if you like, think of Java methods as AspectJ introductions. Java classes are empty (with regard to methods) when you begin. One way to think of it. So with AspectJ you can modularise in ways that Haskell suggests anyhow :-)
You end up with creating quite a complicate and non-trivial library for just implementing something like List<Interface>.
Heterogeneous lists are perhaps an overkill for polymorphic lists modulo subtyping. But there are *many* tradeoffs. For instance, the perhaps easier to comprehend version with existentials and type-safe cast has these problems: - the \exists makes the data opaque; so one better anticipates all operations that are eventually needed in constraints. - polymorphic recursion and existstentials don't quite nicely go together. - you need the wrapper constructor to point out existential quantification.
I don't see a way to store functions in a file. That's the task Clean Dynamics solve.
I guess others know better than I. Storing functions isn't possible AFAIK, with Haskell's Dynamics/Read/Show, what else? Similar problems for existentially quantified data. For the rest, read/show and variations are Ok. Yes, Clean's Dynamics are cool.
-- 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?
It is implemented rather efficiently in Data.Dynamics, say one Int per type. So it is basically the cost of Int comparison, but I don't have performance figures at hand. There is certainly a kind of startup overhead. Say all the Ints have to be produced and registered somewhere, but once all types are around it should be like Int comparison.
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
I guess you want the forall to be an existential quantifier. Anyway, the way the forall is placed, it is really a universal one. So you are saying that you want to get a list of polymorphic implementations, but your actual list comprises actual implementations. So the error message is right. Perhaps enjoy some of this discussion: http://www.haskell.org/pipermail/haskell/2004-February/013600.html
PS The sample in your previous post doesn't run due to lack of hMapOut
Do you mean that I did not include the hMapOut code? -- Map a heterogeneous list to a homogeneous one class HMapOut f r e where hMapOut :: f -> r -> [e] instance HMapOut f HNil e where hMapOut _ _ = [] instance ( HMapOut f l e' , HApply f e e' ) => HMapOut f (HCons e l) e' where hMapOut f (HCons e l) = hApply f e : hMapOut f l I double-checked that the downloadable sources run:
ghci gh-users-040607.hs works.
BTW, yesterday, I really forgot to include this interesting Eq instance: instance Eq AnyMyInterface where (AnyMyInterface x) == (AnyMyInterface y) = x `yaHEq` y Cheers, Ralf
On 10/06/2004, at 3:29 AM, Mike Aizatsky wrote:
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 know whether it's Turing complete, but if you're more interested in how to (ab?)use type classes to perform computations, see a paper named "Fun with Functional Dependencies": http://www.cs.chalmers.se/~hallgren/Papers/wm01.html That shows how you use multi-parameter type classes and functional dependencies to create full functions in the type system. Once you understand that, you might be able to wrap your head around this example: http://www.haskell.org/hawiki/SimulatingDependentTypes which shows how to create an AVL tree data type, with which it is impossible write a function that can unbalance the tree. There is also a very interesting paper posted to the main Haskell mailing list only a few days ago: http://www.eecs.harvard.edu/~ccshan/prepose/ which shows (amongst other things) how to reify _any_ value to a type, i.e. create a new type which represents that (and only that) particular value in the type system, and how to "round-trip" that unique type back to the value it originally came from. I'm not sure if you're interested in type wizardry, but it shows a very impressive amount of static computation that you can do with the type system at compile-time.
The only issue is to get rid of AnyMyInterface around the code. Can you explain me why
Hmm, what's the higher goal of what you're trying to achieve? I, like you, came from a background of object-oriented programming, and I've always managed to avoid making a list containing more than one type after re-thinking about the problem. You can do it, sure, but the typical reasons for doing so in Haskell are very different from doing this in, say, Java. -- % Andre Pang : trust.in.love.to.save
Andre, Thanks for paper pointers.
Hmm, what's the higher goal of what you're trying to achieve? I, like you, came from a background of object-oriented programming, and I've always managed to avoid making a list containing more than one type after re-thinking about the problem. You can do it, sure, but the typical reasons for doing so in Haskell are very different from doing this in, say, Java.
I'm simulating the interaction of different physical entities with particles. Basically I have this: class PhysicalObject a where interact1 :: a -> InteractionParameters -> InteractionResult Also I have the Scene data structure, which has the list of physical objects, read from a configuration file. data Scene = Scene {....., objects :: [AnyPhysicalObject], ....} The Scene is than passed to different simulation algorithms type Simulator = Scene -> SimulationResult All the simulators don't care about different PhysicalObjects. They are even mostly pluggable. All simulator should know is the object interaction with particles. Regards, Mike
participants (3)
-
André Pang -
Mike Aizatsky -
Ralf Laemmel