"parameter(s)" -> "argument(s)"

Author: MatthijsBlom

source_md/a-fistful-of-monads.md

@@ -349,14 +349,14 @@ ghci> landLeft 2 (landRight 1 (landLeft 1 (0,0)))
 When we apply the function `landLeft 1` to `(0,0)` we get `(1,0)`.
 Then, we land a bird on the right side, resulting in `(1,1)`.
 Finally two birds land on the left side, resulting in `(3,1)`.
-We apply a function to something by first writing the function and then writing its parameter, but here it would be better if the pole went first and then the landing function.
+We apply a function to something by first writing the function and then writing its argument, but here it would be better if the pole went first and then the landing function.
 If we make a function like this:
 
 ```{.haskell:hs}
 x -: f = f x
 ```
 
-We can apply functions by first writing the parameter and then the function:
+We can apply functions by first writing the argument and then the function:
 
 ```{.haskell:hs}
 ghci> 100 -: (*3)
@@ -498,7 +498,7 @@ Now that we have a `Nothing`, it gets fed to `landRight (-2)`, but because it's
 
 We couldn't have achieved this by just using `Maybe` as an applicative.
 If you try it, you'll get stuck, because applicative functors don't allow for the applicative values to interact with each other very much.
-They can, at best, be used as parameters to a function by using the applicative style.
+They can, at best, be used as arguments to a function by using the applicative style.
 The applicative operators will fetch their results and feed them to the function in a manner appropriate for each applicative and then put the final applicative value together, but there isn't that much interaction going on between them.
 Here, however, each step relies on the previous one's result.
 On every landing, the possible result from the previous one is examined and the pole is checked for balance.
@@ -531,7 +531,7 @@ Instead of making functions that ignore their input and just return a predetermi
 m >> n = m >>= \_ -> n
 ```
 
-Normally, passing some value to a function that ignores its parameter and always just returns some predetermined value would always result in that predetermined value.
+Normally, passing some value to a function that ignores its argument and always just returns some predetermined value would always result in that predetermined value.
 With monads however, their context and meaning has to be considered as well.
 Here's how `>>` acts with `Maybe`:
 
@@ -678,7 +678,7 @@ ghci> Just 9 >>= (\x -> Just (x > 8))
 Just True
 ```
 
-Because the left parameter of `>>=` is a `Just` value, the lambda is applied to `9` and the result is a `Just True`.
+Because the left argument to `>>=` is a `Just` value, the lambda is applied to `9` and the result is a `Just True`.
 If we rewrite this in `do` notation, we get:
 
 ```{.haskell:hs}
@@ -1295,7 +1295,7 @@ Composing two functions is implemented like so:
 f . g = (\x -> f (g x))
 ```
 
-If the type of `g` is `a -> b` and the type of `f` is `b -> c`, we arrange them into a new function which has a type of `a -> c`, so that its parameter is passed between those functions.
+If the type of `g` is `a -> b` and the type of `f` is `b -> c`, we arrange them into a new function which has a type of `a -> c`, so that its argument is passed between those functions.
 Now what if those two functions were monadic, that is, what if the values they returned were monadic values?
 If we had a function of type `a -> m b`, we couldn't just pass its result to a function of type `b -> m c`, because that function accepts a normal `b`, not a monadic one.
 We could however, use `>>=` to make that happen.

source_md/for-a-few-monads-more.md

@@ -668,7 +668,7 @@ instance Monad ((->) r) where
 
 We've already seen how `pure` is implemented for functions, and `return` is pretty much the same thing as `pure`.
 It takes a value and puts it in a minimal context that always has that value as its result.
-And the only way to make a function that always has a certain value as its result is to make it completely ignore its parameter.
+And the only way to make a function that always has a certain value as its result is to make it completely ignore its argument.
 
 The implementation for `>>=` seems a bit cryptic, but it's really not all that.
 When we use `>>=` to feed a monadic value to a function, the result is always a monadic value.
@@ -722,8 +722,8 @@ addStuff x = let
 
 We see that the reader monad allows us to treat functions as values with a context.
 We can act as if we already know what the functions will return.
-It does this by gluing functions together into one function and then giving that function's parameter to all of the functions that it was glued from.
-So if we have a lot of functions that are all just missing one parameter and they'd eventually be applied to the same thing, we can use the reader monad to sort of extract their future results and the `>>=` implementation will make sure that it all works out.
+It does this by gluing functions together into one function and then giving that function's argument to all of the functions that it was glued from.
+So if we have a lot of functions that are all just missing one argument and they'd eventually be applied to the same thing, we can use the reader monad to sort of extract their future results and the `>>=` implementation will make sure that it all works out.
 
 ## Tasteful stateful computations {#state}
 
@@ -735,7 +735,7 @@ However, some problems are inherently stateful in that they rely on some state t
 While such problems aren't a problem for Haskell, they can be a bit tedious to model sometimes.
 That's why Haskell features a thing called the state monad, which makes dealing with stateful problems a breeze while still keeping everything nice and pure.
 
-[When we were dealing with random numbers](input-and-output.html#randomness), we dealt with functions that took a random generator as a parameter and returned a random number and a new random generator.
+[When we were dealing with random numbers](input-and-output.html#randomness), we dealt with functions that took a random generator as an argument and returned a random number and a new random generator.
 If we wanted to generate several random numbers, we always had to use the random generator that a previous function returned along with its result.
 When making a function that takes a `StdGen` and tosses a coin three times based on that generator, we had to do this:
 
@@ -1219,7 +1219,7 @@ Using this applicative style makes things pretty easy.
 
 So it's kind of like `fmap`, only the function itself is in a context.
 We have to somehow extract it from the context and map it over the `f a` value and then assemble the context back together.
-Because all functions are curried in Haskell by default, we can use the combination of `<$>` and `<*>` to apply functions that take several parameters between applicative values.
+Because all functions are curried in Haskell by default, we can use the combination of `<$>` and `<*>` to apply functions that take several arguments between applicative values.
 
 Anyway, it turns out that just like `fmap`, `<*>` can also be implemented by using only what the `Monad` type class gives us.
 The `ap` function is basically `<*>`, only it has a `Monad` constraint instead of an `Applicative` one.

source_md/functionally-solving-problems.md

@@ -44,10 +44,10 @@ Finally, there's a `-`.
 We pop `10` and `14` from the stack, subtract `14` from `10` and push that back.
 The number on the stack is now `-4` and because there are no more numbers or operators in our expression, that's our result!
 
-Now that we know how we'd calculate any RPN expression by hand, let's think about how we could make a Haskell function that takes as its parameter a string that contains an RPN expression, like `"10 4 3 + 2 * -"` and gives us back its result.
+Now that we know how we'd calculate any RPN expression by hand, let's think about how we could make a Haskell function that takes as its argument a string that contains an RPN expression, like `"10 4 3 + 2 * -"` and gives us back its result.
 
 What would the type of that function be?
-We want it to take a string as a parameter and produce a number as its result.
+We want it to take a string as an argument and produce a number as its result.
 So it will probably be something like `solveRPN :: (Num a) => String -> a`.
 
 ::: {.hintbox}
@@ -385,7 +385,7 @@ heathrowToLondon = [Section 50 10 30, Section 5 90 20, Section 40 2 25, Section
 
 All we need to do now is to implement the solution that we came up with previously in Haskell.
 What should the type declaration for a function that calculates a shortest path for any given road system be?
-It should take a road system as a parameter and return a path.
+It should take a road system as an argument and return a path.
 We'll represent a path as a list as well.
 Let's introduce a `Label` type that's just an enumeration of either `A`, `B` or `C`.
 We'll also make a type synonym: `Path`.
@@ -463,7 +463,7 @@ We do the same thing for `newPathToB`, only everything's mirrored.
 Finally, we return `newPathToA` and `newPathToB` in a pair.
 
 Let's run this function on the first section of `heathrowToLondon`.
-Because it's the first section, the best paths on A and B parameter will be a pair of empty lists.
+Because it's the first section, the best paths on A and B argument will be a pair of empty lists.
 
 ```{.haskell:hs}
 ghci> roadStep ([], []) (head heathrowToLondon)
@@ -513,7 +513,7 @@ We have the function that finds an optimal path based on, now we just have to re
 
 First off, let's make a function that takes a list and splits it into groups of the same size.
 We'll call it `groupsOf`.
-For a parameter of `[1..10]`, `groupsOf 3` should return `[[1,2,3],[4,5,6],[7,8,9],[10]]`.
+For an argument of `[1..10]`, `groupsOf 3` should return `[[1,2,3],[4,5,6],[7,8,9],[10]]`.
 
 ```{.haskell:hs}
 groupsOf :: Int -> [a] -> [[a]]