Replace template<class> with template<typename>

cf. hmemcpy/milewski-ctfp-pdf#309

Author: ktgw0316

english/part1/ch01.md

@@ -111,7 +111,7 @@ There are two extremely important properties that the composition in any categor
 When dealing with functions, the identity arrow is implemented as the identity function that just returns back its argument. The implementation is the same for every type, which means this function is universally polymorphic. In C++ we could define it as a template:
 
 ```cpp
-template<class T> T id(T x) { return x; }
+template<typename T> T id(T x) { return x; }
 ```
 
 \noindent

english/part1/ch02.md

@@ -194,7 +194,7 @@ unit _ = ()
 In C++ you would write this function as:
 
 ```cpp
-template<class T>
+template<typename T>
 void unit(T) {}
 ```
 

english/part1/ch03.md

@@ -103,13 +103,13 @@ The former translates into equality of morphisms in the category $\Hask$ (or $\S
 The closest one can get to declaring a monoid in C++ would be to use the C++20 standard's concept feature.
 
 ```cpp
-template<class T>
+template<typename T>
 struct mempty;
 
-template<class T>
+template<typename T>
   T mappend(T, T) = delete;
 
-template<class M>
+template<typename M>
   concept Monoid = requires (M m) {
     { mempty<M>::value() } -> std::same_as<M>;
     { mappend(m, m); } -> std::same_as<M>;

english/part1/ch04.md

@@ -103,7 +103,7 @@ We want to modify the functions `toUpper` and `toWords` so that they piggyback a
 We will “embellish” the return values of these functions. Let's do it in a generic way by defining a template `Writer` that encapsulates a pair whose first component is a value of arbitrary type `A` and the second component is a string:
 
 ```cpp
-template<class A>
+template<typename A>
 using Writer = pair<A, string>;
 ```
 
@@ -185,7 +185,7 @@ So here's the recipe for the composition of two morphisms in this new category w
 If we want to abstract this composition as a higher order function in C++, we have to use a template parameterized by three types corresponding to three objects in our category. It should take two embellished functions that are composable according to our rules, and return a third embellished function:
 
 ```cpp
-template<class A, class B, class C>
+template<typename A, typename B, typename C>
 function<Writer<C>(A)> compose(function<Writer<B>(A)> m1,
                                function<Writer<C>(B)> m2)
 {
@@ -240,7 +240,7 @@ Writer<A> identity(A);
 They have to behave like units with respect to composition. If you look at our definition of composition, you'll see that an identity morphism should pass its argument without change, and only contribute an empty string to the log:
 
 ```cpp
-template<class A>
+template<typename A>
 Writer<A> identity(A x) {
     return make_pair(x, "");
 }
@@ -336,7 +336,7 @@ The particular monad that I used as the basis of the category in this post is ca
 A function that is not defined for all possible values of its argument is called a partial function. It's not really a function in the mathematical sense, so it doesn't fit the standard categorical mold. It can, however, be represented by a function that returns an embellished type `optional`:
 
 ```cpp
-template<class A> class optional {
+template<typename A> class optional {
     bool _isValid;
     A    _value;
 public:

english/part1/ch05.md

@@ -131,7 +131,7 @@ snd (_, y) = y
 In C++, we would use template functions, for instance:
 
 ```cpp
-template<class A, class B>
+template<typename A, typename B>
 A fst(pair<A, B> const & p) {
     return p.first;
 }

english/part1/ch06.md

@@ -272,7 +272,7 @@ data List a = Nil | Cons a (List a)
 can be translated to C++ using the null pointer trick to implement the empty list:
 
 ```cpp
-template<class A>
+template<typename A>
 class List {
     Node<A> * _head;
 public:

english/part1/ch07.md

@@ -194,7 +194,7 @@ This is definitely not a valid transformation, and it will not produce the same
 Functors are easily expressed in Haskell, but they can be defined in any language that supports generic programming and higher-order functions. Let's consider the C++ analog of `Maybe`, the template type `optional`. Here's a sketch of the implementation (the actual implementation is much more complex, dealing with various ways the argument may be passed, with copy semantics, and with the resource management issues characteristic of C++):
 
 ```cpp
-template<class T>
+template<typename T>
 class optional {
     bool _isValid; // the tag
     T    _v;
@@ -210,7 +210,7 @@ public:
 This template provides one part of the definition of a functor: the mapping of types. It maps any type `T` to a new type `optional<T>`. Let's define its action on functions:
 
 ```cpp
-template<class A, class B>
+template<typename A, typename B>
 std::function<optional<B>(optional<A>)>
 fmap(std::function<B(A)> f)
 {
@@ -227,7 +227,7 @@ fmap(std::function<B(A)> f)
 This is a higher order function, taking a function as an argument and returning a function. Here's the uncurried version of it:
 
 ```cpp
-template<class A, class B>
+template<typename A, typename B>
 optional<B> fmap(std::function<B(A)> f, optional<A> opt) {
     if (!opt.isValid())
         return optional<B>{};
@@ -295,15 +295,15 @@ By the way, the `Functor` class, as well as its instance definitions for a lot o
 Can we try the same approach in C++? A type constructor corresponds to a template class, like `optional`, so by analogy, we would parameterize `fmap` with a [*template template parameter*]{.keyword #template_template_parameter}\index{template template parameter} `F`. This is the syntax for it:
 
 ```cpp
-template<template<class> F, class A, class B>
+template<template<typename> F, typename A, typename B>
 F<B> fmap(std::function<B(A)>, F<A>);
 ```
 
 \noindent
 We would like to be able to specialize this template for different functors. Unfortunately, there is a prohibition against partial specialization of template functions in C++. You can't write:
 
 ```cpp
-template<class A, class B>
+template<typename A, typename B>
 optional<B> fmap<optional>(
     std::function<B(A)> f, optional<A> opt)
 ```
@@ -312,7 +312,7 @@ optional<B> fmap<optional>(
 Instead, we have to fall back on function overloading, which brings us back to the original definition of the uncurried `fmap`:
 
 ```cpp
-template<class A, class B>
+template<typename A, typename B>
 optional<B> fmap(std::function<B(A)> f, optional<A> opt)
 {
     if (!opt.isValid())
@@ -360,7 +360,7 @@ instance Functor List where
 If you are more comfortable with C++, consider the case of a `std::vector`, which could be considered the most generic C++ container. The implementation of `fmap` for `std::vector` is just a thin encapsulation of `std::transform`:
 
 ```cpp
-template<class A, class B>
+template<typename A, typename B>
 std::vector<B> fmap(std::function<B(A)> f, std::vector<A> v)
 {
     std::vector<B> w;
@@ -468,7 +468,7 @@ instance Functor (Const c) where
 This might be a little clearer in C++ (I never thought I would utter those words!), where there is a stronger distinction between type arguments — which are compile-time — and values, which are run-time:
 
 ```cpp
-template<class C, class A>
+template<typename C, typename A>
 struct Const {
     Const(C v) : _v(v) {}
     C _v;
@@ -479,7 +479,7 @@ struct Const {
 The C++ implementation of `fmap` also ignores the function argument and essentially re-casts the `Const` argument without changing its value:
 
 ```cpp
-template<class C, class A, class B>
+template<typename C, typename A, typename B>
 Const<C, B> fmap(std::function<B(A)> f, Const<C, A> c) {
     return Const<C, B>{c._v};
 }

english/part1/ch08.md

@@ -218,7 +218,7 @@ As I mentioned before, one way of implementing sum types in C++ is through class
 The base class must define at least one virtual function in order to support dynamic casting, so we'll make the destructor virtual (which is a good idea in any case):
 
 ```cpp
-template<class T>
+template<typename T>
 struct Tree {
     virtual ~Tree() {}
 };
@@ -228,7 +228,7 @@ struct Tree {
 The `Leaf` is just an `Identity` functor in disguise:
 
 ```cpp
-template<class T>
+template<typename T>
 struct Leaf : public Tree<T> {
     T _label;
     Leaf(T l) : _label(l) {}
@@ -239,7 +239,7 @@ struct Leaf : public Tree<T> {
 The `Node` is a product type:
 
 ```cpp
-template<class T>
+template<typename T>
 struct Node : public Tree<T> {
     Tree<T> * _left;
     Tree<T> * _right;
@@ -251,7 +251,7 @@ struct Node : public Tree<T> {
 When implementing `fmap` we take advantage of dynamic dispatching on the type of the `Tree`. The `Leaf` case applies the `Identity` version of `fmap`, and the `Node` case is treated like a bifunctor composed with two copies of the `Tree` functor. As a C++ programmer, you're probably not used to analyzing code in these terms, but it's a good exercise in categorical thinking.
 
 ```cpp
-template<class A, class B>
+template<typename A, typename B>
 Tree<B> * fmap(std::function<B(A)> f, Tree<A> * t)
 {
     Leaf<A> * pl = dynamic_cast <Leaf<A>*>(t);

english/part1/ch10.md

@@ -82,7 +82,7 @@ alpha :: F a -> G a
 Keep in mind that it's really a family of functions parameterized by `a`. This is another example of the terseness of the Haskell syntax. A similar construct in C++ would be slightly more verbose:
 
 ```cpp
-template<class A> G<A> alpha(F<A>);
+template<typename A> G<A> alpha(F<A>);
 ```
 
 \noindent

japanese/part1/ch01.md

@@ -113,7 +113,7 @@ f ∷ A → B
 関数を扱うとき、恒等射は引数をそのまま返す恒等関数として実装される。この実装はどの型でも同じであり、この関数は普遍的に多相 (universally polymorphic) であることを意味する。これはC++ではテンプレートとして定義できる。
 
 ```cpp
-template<class T> T id(T x) { return x; }
+template<typename T> T id(T x) { return x; }
 ```
 
 \noindent