When you have a multiparameter typeclass, by default, the type variables are considered independently. So when the type inferencer is trying to figure out which instance of class Foo a b to choose, it has to determine a and b independently, then go look check to see if the instance exists. With functional dependencies, we … Read more
liftA, liftM, fmap, and . should all be the same function, and they must be if they satisfy the functor law: fmap id = id However, this is not checked by Haskell. Now for Applicative. It’s possible for ap and <*> to be distinct for some functors simply because there could be more than one … Read more
I tend to see no issue with only requiring constraints on functions. The issue is, I suppose, that your data structure no longer models precisely what you intend it to. On the other hand, if you think of it as a data structure first and foremost, then that should matter less. I feel like I … Read more
Actually, it’s a “functional dependency”. In this case that means that m uniquely identifies w — the type m determines the type w. (This may be a better link.)
Yes, you are correct, you are looking for algebraic data types. There is a great tutorial on them at Learn You a Haskell. For the record, the concept of an abstract class from OOP actually has three different translations into Haskell, and ADTs are just one. Here is a quick overview of the techniques. Algebraic … Read more
The instance declaration you made is the correct way to go. It seems you forgot to remove that faulty deriving clause from the original data declaration. data Operace = Op (Int->Int->Int) String (Int->Int->Int) instance Show Operace where show (Op op str inv) = show str
TypeSynonymInstances is perfectly safe. Since anything potentially fancy like partially applied type synonyms is disallowed, it has exactly the same effect as typing out the the right hand side of the type synonym in the instance head, i.e. type Foo a = ([a], [a]) instance Bar (Foo a) is the same as instance Bar ([a], … Read more
Consider a situation where both the type and class exist in the same program. The type can be an instance of the class, but that’s rather trivial. More interesting is that you can write a function fromProblemClass :: (CProblem p s a) => p s a -> TProblem s a. The refactoring you performed is … Read more
Well this is quite complicated. Lets start with the ambiguous error: <interactive>:1:1: Ambiguous type variable `b0′ in the constraint: (Arity b0) arising from a use of `arity’ Probable fix: add a type signature that fixes these type variable(s) In the expression: arity foldr In an equation for `it’: it = arity foldr Normally, without overlapping … Read more
The inability to control imports of instances is one of the trade-offs the Haskell typeclass system makes. Here’s an example in a hypothetical Haskell dialect where you can: Foo.hs: module Foo where data Foo = FooA | FooB deriving (Eq, Ord) Bar.hs: module Bar (myMap) where import Data.Map (Map) import qualified Data.Map as Map import … Read more