On Wed, 2008-10-15 at 11:56 -0700, Daryoush Mehrtash wrote: > The equivalent won't compile in Haskell, because the actual > return > type does matter, and *is determined by the calling code*. > Our > fictional GetListOfData can't return a List or a Mylist > depending on > some conditional, in fact it can't explicitly return either > one at > all, because the actual type of the result, as determined by > the > caller, could be either one, or something else entirely > (ignoring the > IO bit for the time being). > > > I have had an unresolved issue on my stack of Haskell vs Java that I > wonder if your observation explains. > > If you notice java generics has all sort of gotchas (e.g. > http://www.ibm.com/developerworks/java/library/j-jtp01255.html). I > somehow don't see this discussion in Haskell. I wonder if haskell's > model of letting the caller determine the result type has advantage in > that you don't have all the complexity you would have if you let the > API determine their types.
These look more like unfortunate interactions between generics and the pre-existing Java language than anything else. Covariance isn't really an issue in Haskell, since Haskell lacks sub-typing; the various unfortunate consequences of type erasure in Java are avoided by the fact that Haskell types lack constructors, so the user never expects to be able to conjure up a value of an unknown type. jcc _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
