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] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon university KF8NH
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
