3 ms·

Oops. So, I'm even more confused now. You know show. read is inferred just fine, and that means typeclasses break inference?

• kd0amg 13y ago
  You know show. read is inferred just fine The "internal, ambiguous type" matters when you try to actually invoke (show . read) on some String. If you want to actually use that function, you're stuck inserting a type annotation, which would lead many people to say that (show . read) is not "inferred just fine."
  • nousernamesleft 13y ago
    >The "internal, ambiguous type" matters when you try to actually invoke (show . read) on some String There is no internal ambiguous type. It is not a concrete type, it is a type variable. But it is inferred just fine. It is (Read a => a). >which would lead many people to say that (show . read) is not "inferred just fine." Even if you were to erroneously say that, it isn't type classes that is the problem.
    • lpw25 13y ago
      > Even if you were to erroneously say that, it isn't type classes that is the problem. I'm pretty sure it is. For example, see section 3.7 of "Type classes: an exploration of the design space" by SPJ et al.
• tel 13y ago
  I guess it depends on what you we both mean by "breaks inference". I think the fact that it readily infers a type for a function made ambiguous by lost information to be a flaw of inference. The algorithm works, but I think the demonstrates that HM doesn't come through unscathed with the inclusion of typeclasses.