On 2008 Oct 16, at 22:22, leledumbo wrote:
... If there isn't enough information to set a concrete type at the call, type inference fails. This is what you get with strong typing.
In my case, where does type inference fail? Strong typing is good, but quite confusing when combined with polymorphism.
Consider the types of "show" and "read": show :: Show a => a -> String -- you could use any variable names but read :: Read b => String -> b -- I'm doing it this way to make a point and therefore the type of (read . show) is (read . show) :: (Show a, Read b) => a -> b -- a cannot be unified with b! It has no clue that (read . show) are effectively inverses, nor can it; you can't describe that with Show and Read. It would be possible to combine the Show and Read classes into a single class which allowed this to work. What you lose is flexibility: it is possible to define Show for types which cannot be read. Consider, for example, functions: the Typeable class can be used to show a function in terms of its types (as long as it isn't polymorphic), but that's useless to read back in. And outputting a function such that it could be read back in would require either disassembler+assembler or a virtual machine runtime like the JVM or .NET/Mono. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH