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
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