How to convert following Java implementation into Haskell?
The major purpose here is having a list that contains various elements which are sub-type of a particular in
Simple answer: don't! Haskell is not an OO language, and it's not much good pretending it is and just trying to translate inheritance patterns to a mixture of type classes and ADTs.
Your List
in Java is quite substantially different from a Foo a => [a]
in Haskell: such a signature actually means forall a . Foo a => [a]
. The a
is basically an extra argument to the function, i.e. it can be chosen from the outside what particular Foo
instance is used here.
Quite the opposite in Java: there you don't have any control of what types are in the list at all, only know that they implement the Foo
interface. In Haskell, we call this an existential type, and generally avoid it because it's stupid. Ok, you disagree – sorry, you're wrong!
...No, seriously, if you have such an existential list, the only thing you can ever do1 is execute the bar
action. Well, then why not simply put that action in the list right away! IO()
actions are values just like anything else (they aren't functions; anyway those can be put in lists just as well). I'd write your program
xs :: [IO ()]
xs = [bar Bar1, bar Bar2]
{-# LANGUAGE ExistentialQuantification #-}
data AFoo = forall a. Foo a => AFoo a
xs :: [AFoo]
xs = [AFoo Bar1, AFoo Bar2]
main = mapM_ (\(AFoo f) -> bar f) xs
As this has become quite a rant: I do acknoledge that OO style is for some applications more convenient than Haskell's functional style. And existentials do have their valid use cases (though, like chunksOf 50, I rather prefer to write them as GADTs). Only, for lots of problems Haskell allows for far more concise, powerful, general, yet in many ways simpler solutions than the "if all you have's a hammer..." inheritance you'd use in OO programming, so before using existentials you should get a proper feeling for Haskell's "native" features.
1Yeah, I know you can also do "typesafe dynamic casts" etc. in Java. In Haskell, there's the Typeable
class for this kind of stuff. But you might as well use a dynamic language right away if you take such paths.