More fixes

Author: jhrcek

01-FP-Philosophical-Foundations/01-Composition-Everywhere.md

@@ -16,9 +16,9 @@ But what kinds of things do we compose? In Functional Programming, we compose ty
 
 ## Composing Types Algebraically
 
-Algebraic Data Types (ADTs) use Algerbra to define the total number of values a given type (i.e. named Set) can have.
+Algebraic Data Types (ADTs) use Algebra to define the total number of values a given type (i.e. named Set) can have.
 
-There are two videos worth watching in this regard. The table and visualizations that follow merely summarizes their points, except for the ideas behind the `List` and `Tree` types in the second video.
+There are two videos worth watching in this regard. The table and visualizations that follow merely summarize their points, except for the ideas behind the `List` and `Tree` types in the second video.
 - ['Algebraic Data Types' as "Composable Data Types" (stop at 12:40)](https://youtu.be/Up7LcbGZFuo?t=1155)
     - Same ideas already explained in the above "Power of Composition" video:
     - It uses a different syntax than `PureScript` but the ideas still apply.
@@ -27,11 +27,11 @@ There are two videos worth watching in this regard. The table and visualizations
     - explains the "algebraic laws" behind ADTs
     - covers `List`s and `Tree`s (unlike first video)
 
-| Name | Math Operator | Logic Operator | PureScript Type | Idea
-| - | - | - | - |
-| Product Type | `x * y` | AND | `Tuple` | "One value from type `x` **AND** one value from type `y`"
-| Sum Type | `x + y` | OR | `Either` | "One value from type `x` **OR** one value from type `y`"
-| Exponential Type | `y^x` | ??? | `InputType -> OutputType` | ???
+| Name | Math Operator | Logic Operator | PureScript Type | Idea |
+| - | - | - | - | - |
+| Product Type | `x * y` | AND | `Tuple` | "One value from type `x` **AND** one value from type `y`" |
+| Sum Type | `x + y` | OR | `Either` | "One value from type `x` **OR** one value from type `y`" |
+| Exponential Type | `y^x` | ??? | `InputType -> OutputType` | ??? |
 
 ![Composing Types](./assets/Composing-Types.svg)
 

01-FP-Philosophical-Foundations/04-Lazy-vs-Strict.md

@@ -9,9 +9,9 @@ This is "Lazy evaluation." Your parent tells you to _remember_ to do some chore
 | Term | Definition | Pros | Cons
 | - | - | - | - |
 | Strict | computes its results immediately | Expensive computations can be run at the most optimum time | Wastes CPU cycles and memory for storing/evaluating expensive computations that are unneeded/unused |
-| Lazy | defers compututation until its needed | Saves CPU cycles and memory: unneeded/unused computations are never computed | When computations will occur every time, this adds unneeded overhead
+| Lazy | defers computation until its needed | Saves CPU cycles and memory: unneeded/unused computations are never computed | When computations will occur every time, this adds unneeded overhead
 
-To make something lazy, we turn it into a function. This function takes one argument (`Unit`) and returns the value we desire. This is called a `thunk`: a computation that we know how to do but have not yet executed yet. To run the code stored in the `thunk`, we use the phrase `forcing the thunk`.
+To make something lazy, we turn it into a function. This function takes one argument (`Unit`) and returns the value we desire. This is called a `thunk`: a computation that we know how to do but have not executed yet. To run the code stored in the `thunk`, we use the phrase `forcing the thunk`.
 ```purescript
 -- Given an Int, I can return another Int
 strictlyCompute :: Int -> Int

01-FP-Philosophical-Foundations/05-Looping-via-Recursion.md

@@ -137,7 +137,7 @@ Just 1
 
 ## Other Loops
 
-The following Purescript examples are very _crude_ ways of mimicking the following loops. More appropriate examples would require explaning and using type classes like `Foldable` and `Monad` (intermediate FP concepts). Thus, take these examples with a grain of salt.
+The following Purescript examples are very _crude_ ways of mimicking the following loops. More appropriate examples would require explaining and using type classes like `Foldable` and `Monad` (intermediate FP concepts). Thus, take these examples with a grain of salt.
 
 ### While
 

01-FP-Philosophical-Foundations/06-Type-Classes.md

@@ -14,7 +14,7 @@ Video: [Code Reuse in PureScript: Functions, Type Classes, and Interpreters](htt
 
 ## Where Do Type Classes Come From?
 
-Type classes are usually "encodings" of various concepts from Category Theory. Category Theory (herafter referred to as 'CT') is all about the various ways we can compose functions and do so while adhering to specific laws. It's typically used for control flow (e.g. FP-style "if then else" statements, loops, etc.).
+Type classes are usually "encodings" of various concepts from Category Theory. Category Theory (hereafter referred to as 'CT') is all about the various ways we can compose functions and do so while adhering to specific laws. It's typically used for control flow (e.g. FP-style "if then else" statements, loops, etc.).
 
 Type classes make developers productive. They enable programmers...
     - to write 1 line of code that is the equivalent of writing 100s of lines of code.
@@ -37,10 +37,10 @@ Thus, type classes abstract general concepts into an "interface" that can be imp
 2. (Almost Always) The laws by which implementations of a type class must abide.
     - These laws guarantee certain properties, increasing developers' confidence that their code works as expected.
     - They also help one to know how to refactor code. Given `left-hand-side == right-hand-side`, evaluating code on the left may be more expensive (memory, time, IO, etc.) than the code on the right.
-    - **Laws cannot be enforced by the compiler.** For example, one could define a a type class' instance for some type which satisfies the type signature. However, the implementation of that instance might not satisfy the type class' law(s). The compiler can verify that the type signature is correct, but not the implementation. Thus, one will need to insure an instance's lawfulness via tests, (usually by using a testing library called `quickcheck-laws`, which is covered later in this repo)
+    - **Laws cannot be enforced by the compiler.** For example, one could define a type class' instance for some type which satisfies the type signature. However, the implementation of that instance might not satisfy the type class' law(s). The compiler can verify that the type signature is correct, but not the implementation. Thus, one will need to insure an instance's lawfulness via tests, (usually by using a testing library called `quickcheck-laws`, which is covered later in this repo)
 3. (Frequently) The functions/values that can be derived once one implements the type class.
     - Most of the power/flexibility of type classes come from the combination of the main functions/values implemented in a type class' definition and these derived functions. When a type class extends another, the type class' power increases, its flexibility decreases, and its costs increase.
-        - For example, one can consider `Apply` and `Monad`. `Apply` is a less powerful typeclass than `Monad` because it requires its arguments to be known at compile-time whereas `Monad`'s arguments must be known at runtime. However, `Apply` is more flexibile because it can compute things in parallel whereas `Monad` must compute things sequentially.
+        - For example, one can consider `Apply` and `Monad`. `Apply` is a less powerful typeclass than `Monad` because it requires its arguments to be known at compile-time whereas `Monad`'s arguments must be known at runtime. However, `Apply` is more flexible because it can compute things in parallel whereas `Monad` must compute things sequentially.
 
 ### Examples
 

02-Build-Tools/01-Dependency-Managers/01-Bower-Explained.md

@@ -46,7 +46,7 @@ The following issue is happening less and less frequently due to the PureScript
 
 #### Annoyance Defined
 
-If a compiler release that includes breaking changes was released recently, it will take some time for libraries in the ecosystem to become compatible with that release. If you are using Bower as your dependency manager, it may try to install libraries that are and are not compatible with the new release, creating problems.
+If a compiler release that includes breaking changes was released recently, it will take some time for libraries in the ecosystem to become compatible with that release. If you are using Bower as your dependency manager, it may try to install libraries that are not compatible with the new release, creating problems.
 
 #### Recommended Guidelines
 

02-Build-Tools/01-Dependency-Managers/02-Spago-Explained.md

@@ -15,7 +15,7 @@ When a new PureScript release with breaking changes occurs, using `bower` is pai
     - fix a bug in its implementation
     - update a library to a newer PS release if it hasn't been done yet
     - update a library's transitive dependency to a newer release without needing to submit a PR
-- add local or cloud-based dependencies not found in the official packaget set
+- add local or cloud-based dependencies not found in the official package set
     - a project you use frequently, like a custom `Prelude` library.
     - a project with your preferred aliases to functions/values (i.e. using `<!>` for `map` instead of `<$>`)
 
@@ -31,13 +31,13 @@ A **package** in this context is 4 things:
 
 Thus, a package is a unique named `repo-tag-dependencies` combination (e.g. `prelude` could indicate the [Prelude repo at the 'v0.4.1' tag](https://github.com/purescript/purescript-prelude/tree/v4.1.0)).
 
-A **package set** consists of a set of packages. It's a JSON-like file that maps a package name to its corresponding `repo-tag-dependencies` combination. A package set gets **verified** to ensure that its set of packages compile together on a given PureScript compiler erelease. Once verified, they are considered "immutable."
+A **package set** consists of a set of packages. It's a JSON-like file that maps a package name to its corresponding `repo-tag-dependencies` combination. A package set gets **verified** to ensure that its set of packages compiles together on a given PureScript compiler release. Once verified, they are considered "immutable."
 
 A package set includes all dependencies: direct ones and their transitive dependencies. For example, if the set includes the package, `PackA`, which depends on the package, `PackB`, the package set must include both packages:
 - `PackA`
     - Version: `v1.0.0`
     - Repo: `https://exampleRepo.com/PackA.git`
-    - Dependencies: `["PackB"]` (spago will look up "PackB" in the packaget set to resolve it)
+    - Dependencies: `["PackB"]` (spago will look up "PackB" in the package set to resolve it)
 - `PackB`
     - Version: `v1.0.0`
     - Repo: `https://exampleRepo.com/PackB.git`

02-Build-Tools/01-Dependency-Managers/03-Why-We-Need-Both.md

@@ -6,8 +6,8 @@ Updating each library in the ecosystem to account for those breaking changes is
 
 In our above analogy, the `purescript-prelude` library and other libraries with no dependencies are the "roots" of the ecosystem. As they get updated, the libraries that depend on them (i.e. the "branches") can now be updated. A "leaf" corresponds to a library which has no dependents.
 
-A package set is immutable. Thus, one cannot add to the packaget set a package that has been updated to the new release unless all of the packages in the package set can also be updated.
+A package set is immutable. Thus, one cannot add to the package set a package that has been updated to the new release unless all of the packages in the package set can also be updated.
 
-During that transitionary time, `spago` cannot help. Rather, we must depend on `Bower` to slowly update each library to its new version that depends on transitive libraries that have been updated to new versions.
+During that transitional time, `spago` cannot help. Rather, we must depend on `Bower` to slowly update each library to its new version that depends on transitive libraries that have been updated to new versions.
 
 Again, `spago` is more suited for application developers and `bower` is more suited for library developers.