The separate discussion that you're answering to is interesting though. I'd like to know how you define a type class, and in which way that definition invalidates Scala's encoding of them. This is neither a challenge nor sarcasm. I'm genuinely interested.
-
So - if type classes *must* have guaranteed global instance uniqueness, then that's fair - Scala doesn't have type classes according to that definition. But then - why do you consider that Haskell, as implemented in GHC, does?
Haskell, the language will refuse to compile it. Simply, it violates the language standard. You must turn off this standard to break the rules. Though I'm much more interested in the question, "is there a valid or practical reason to turn off those rules?" Hard: no.
-
-
Yes, I agree with that: Haskell, the language, has that guarantee. But GHC, one possible but popular implementation of the language, doesn't. My point has always been GHC doesn't have type classes according to that definition, not Haskell doesns't.
-
Right, but from my PoV, this is just holding up a trophy (or not). What are the practical consequences? Much more useful and interesting question. Does Scala have functional dependencies? Not in any *useful* sense. What about dependent types? Again, no. Type-classes? Also no.
- Show replies
New conversation -
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.