Your List<Foo>
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]
That said, if you absolutely insist you can have existential lists in Haskell as well:
{-# 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.