Would you please explain this a bit more: 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.
Thanks, daryoush On Wed, Oct 15, 2008 at 12:04 PM, Jonathan Cast <[EMAIL PROTECTED]>wrote: > 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
