4 ms·

No they don't. > :t read . show read . show :: (Read c, Show a) => a -> c

• tel 13y ago
  That's not what I typed: I did `show . read` which is type `String -> String` and has an internal, ambiguous type.
  • nousernamesleft 13y ago
    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.