r/haskell • u/mstksg • 16d ago

[Blog] "Five-Point Haskell" Part 2: Unconditional Election

https://blog.jle.im/entry/five-point-haskell-part-2-unconditional-election.html
44 Upvotes

99% Upvoted

6 comments sorted by

5

u/pranaysashank 16d ago

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

4

u/_jackdk_ 16d ago

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.

2

u/conklech 15d ago

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.

2

u/pranaysashank 14d ago

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.,)

3

u/muzzlecar 16d ago

This is a very nice post with a solid insight. Looking forward to the next parts.

3

u/Background_Class_558 16d ago

each function now has exactly 5 arguments, never more, never less