in practice people often compile with warnings enabled
-
-
Replying to @puffnfresh @Iceland_jack
In practice, it’s actually rather hard to put yourself in that situation unintentionally. My point is more that global uniqueness isn’t guaranteed, not that it’s hard to achieve :)
1 reply 0 retweets 0 likes -
Replying to @NicolasRinaudo @Iceland_jack
so "not in practice (but actually kinda in practice)"
1 reply 0 retweets 0 likes -
Replying to @puffnfresh @Iceland_jack
No, I disagree with that. It’s not at all enforced by default, in practice. That’s just far less of an issue, in practice, than people make it out to be.
1 reply 0 retweets 0 likes -
In practice, Haskell has global type-class uniqueness. That's not the only reason Haskell type-classes are superior.https://www.youtube.com/watch?v=hIZxTQP1ifo …
1 reply 0 retweets 2 likes -
Fair enough - what did I miss in my (nasty) bit of code? Doesn't it expose exactly the fact that global uniqueness is not guaranteed by ghc? Who's got the bigger type class implementation is another debate entirely and not at all the point I was making, sorry if it was unclear
1 reply 0 retweets 2 likes -
The argument is practical Write Haskell; never use orphan instances. This is achievable with little/no penalty Write Scala; never use orphan instances. With this commitment, it's difficult & there's no sweet spot Scala does not have type-classes in any general practical sense
2 replies 0 retweets 0 likes -
That is entirely besides the point though. My point is: GHC doesn't enforce global instance uniqueness. This is demonstrably true, but exhibiting a program in which global instance uniquess is violated. Whether or not it's easy to avoid is another discussion
2 replies 0 retweets 1 like -
Whether or not it's easy to avoid is the *practical* discussion. GHC doesn't enforce it; Haskell does. Neither of these are particularly interesting to me, but I thought we were talking about practical application.
1 reply 0 retweets 0 likes -
But it's impossible to avoid if you use GHC and have external dependencies though, right? Isn't that practical?
2 replies 0 retweets 0 likes
Just to be clear, when you say "external dependencies", you're talking about the potential for some external library to have orphan instances, right?
-
-
Yes - or to expose functions that abuse them like my code does.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.