• Choose a category
• All
• Classic-Fiction

Also, if you examine the type declaration for these functions, you’ll see that they can operate only on vectors of the same type, and the numbers involved must also be of the type that is contained in the vectors. We can’t add together a Vector Int and a Vector Double.

Notice that we didn’t put a Num class constraint in the data declaration. As explained in the previous section, even if we put it there, we would still need to repeat it in the functions.

Once again, it’s very important to distinguish between the type constructor and the value constructor. When declaring a data type, the part before the = is the type constructor, and the constructors after it (possibly separated by | characters) are value constructors. For instance, giving a function the following type would be wrong:

Vector a a a -> Vector a a a -> a

This doesn’t work because the type of our vector is Vector a, and not Vector a a a. It takes only one type parameter, even though its value constructor has three fields.

Now, let’s play around with our vectors.

ghci> Vector 3 5 8 `vplus` Vector 9 2 8

Vector 12 7 16

ghci> Vector 3 5 8 `vplus` Vector 9 2 8 `vplus` Vector 0 2 3

Vector 12 9 19

ghci> Vector 3 9 7 `vmult` 10

Vector 30 90 70

ghci> Vector 4 9 5 `dotProd` Vector 9.0 2.0 4.0

74.0

ghci> Vector 2 9 3 `vmult` (Vector 4 9 5 `dotProd` Vector 9 2 4)

Vector 148 666 222

Derived Instances

In Type Classes 101 in Type Classes 101, you learned that a type class is a sort of an interface that defines some behavior, and that a type can be made an instance of a type class if it supports that behavior. For example, the Int type is an instance of the Eq type class because the Eq type class defines behavior for stuff that can be equated. And because integers can be equated, Int was made a part of the Eq type class. The real usefulness comes with the functions that act as the interface for Eq, namely == and /=. If a type is a part of the Eq type class, we can use the == functions with values of that type. That’s why expressions like 4 == 4 and "foo" == "bar" type check.

Haskell type classes are often confused with classes in languages like Java, Python, C++ and the like, which trips up a lot of programmers. In those languages, classes are a blueprint from which we create objects that can do some actions. But we don’t make data from Haskell type classes. Instead, we first make our data type, and then we think about how it can act. If it can act like something that can be equated, we make it an instance of the Eq type class. If it can act like something that can be ordered, we make it an instance of the Ord type class.

Let’s see how Haskell can automatically make our type an instance of any of the following type classes: Eq, Ord, Enum, Bounded, Show, and Read. Haskell can derive the behavior of our types in these contexts if we use the deriving keyword when making our data type.

Equating People

Consider this data type:

data Person = Person { firstName :: String

, lastName :: String

, age :: Int

}

It describes a person. Let’s assume that no two people have the same combination of first name, last name, and age. If we have records for two people, does it make sense to see if they represent the same person? Sure it does. We can try to equate them to see if they are equal. That’s why it would make sense for this type to be part of the Eq type class. We’ll derive the instance.

data Person = Person { firstName :: String

, lastName :: String

, age :: Int

} deriving (Eq)

When we derive the Eq instance for a type and then try to compare two values of that type with == or /=, Haskell will see if the value constructors match (there’s only one value constructor here though), and then it will check if all the data contained inside matches by testing each pair of fields with ==. However, there’s a catch: The types of all the fields also must be part of the Eq type class. But since that’s the case with both String and Int, we’re okay.

First, let’s make a few