Re: [Haskell-cafe] Fun with multi-parameter type classes
Hi,
I've been getting into Haskell over the past few months and have just come up against a bit of a brick wall when trying to encapsulate some of the data structures in my code nicely. Basically what I want to have, is a type class where one of the intermediate values is opaque with respect to code using its implementations. This is a simplified version of what I'm trying to accomplish:
class Foo t where encode :: String -> t decode :: t -> String
instance Foo Int where encode = read decode = show
test = decode . encode
This currently fails, because the type checker insists on trying to figure out what its type should be - even though it shouldn't be needed.
The intermediate type /is/ needed---it's a (hidden) parameter to your `encode' and `decode' functions. Why do you think it shouldn't be? <snip> Jon Cast
Jon Cast wrote:
The intermediate type /is/ needed---it's a (hidden) parameter to your `encode' and `decode' functions. Why do you think it shouldn't be?
Because I couldn't see the woods for the trees. I think I had almost figured out what I was asking (the impossible) before your message appeared. I've actually been getting quite confused over this for quite a while and got a lot of it sorted out while I wrote the original email. That's why the subject doesn't match the body at all - I completly rewrote the message several times as I figured out what was going on, but forgot to update the subject. Thanks, Sam
Sam Mason writes:
Jon Cast wrote:
The intermediate type /is/ needed---it's a (hidden) parameter to your `encode' and `decode' functions. Why do you think it shouldn't be?
Because I couldn't see the woods for the trees. I think I had almost figured out what I was asking (the impossible) before your message appeared. ...
Don't forget that this is the toplevel business, not a universal "disease". GHCi says Prelude> :t (show . read) (show . read) :: String -> String and doesn't complain. But if you define bz = show . read the attempt to load this definition (file: ctest.hs) results in: ctest.hs:3: Ambiguous type variable `a' in these top-level constraints: `Read a' arising from use of `read' at ctest.hs:5 `Show a' arising from use of `show' at ctest.hs:5 Failed, modules loaded: none. Prelude> So, as one of my friends used to say: it should be obvious for everybody that what is obvious for one, need not be obvious for the others... Jerzy Karczmarczuk
karczma wrote:
Don't forget that this is the toplevel business, not a universal "disease". GHCi says
Prelude> :t (show . read) (show . read) :: String -> String
and doesn't complain. But if you define
bz = show . read
the attempt to load this definition (file: ctest.hs) results in:
ctest.hs:3: Ambiguous type variable `a' in these top-level constraints: `Read a' arising from use of `read' at ctest.hs:5 `Show a' arising from use of `show' at ctest.hs:5 Failed, modules loaded: none. Prelude>
OK, you've got me interested! Why doesn't GHCi complain about the ambiguity?
So, as one of my friends used to say: it should be obvious for everybody that what is obvious for one, need not be obvious for the others...
Suitably abstruse!
participants (3)
-
Jon Cast -
karczma -
Sam Mason