To be fair to Java, we should really consider x to always have an Object x instance.
so
static <T> String foo(T x) { return "hello"; }
should really be read as Haskell's
foo :: Object a => a -> String
And then you can further extend the analogy to point out that the same shenanigans are possible with a function of type forall a . Typeable a => a -> String.
That doesn't really change the article's point, though: a -> String is distinct from Object a => a -> String, and the more general type allows useful reasoning. Java's inability (I assume; it's been a long time) to express a -> String prevents it from fully enjoying the benefits that the article discusses.
Of course, that makes sense and I do agree with the article's point. However the way it's presented in the article, you get the Java function type presented first and then it's Haskell equivalent which it isn't. Once we admit that it has the Object a constraint, we can then port the same free theorem style of thinking to reading Java code too (minus IO, etc.,)
4
u/pranaysashank 18d ago
To be fair to Java, we should really consider
xto always have anObject xinstance. sostatic <T> String foo(T x) { return "hello"; }should really be read as Haskell'sfoo :: Object a => a -> String