Convert Maybe to Option to match fp-ts

Author: danieljharvey

README.md

@@ -6,11 +6,11 @@ Click on the words for information about subjects and things.
 
 [Intro](https://github.com/danieljharvey/functional-programming-is-boring/blob/master/intro.md)
 
-### Lesson 1 - Maybe
+### Lesson 1 - Option
 
-[Information](https://github.com/danieljharvey/functional-programming-is-boring/blob/master/slides/lesson1-maybe.md)
+[Information](https://github.com/danieljharvey/functional-programming-is-boring/blob/master/slides/lesson1-option.md)
 
-[Exercises](https://github.com/danieljharvey/functional-programming-is-boring/blob/master/src/lesson1-maybe.ts)
+[Exercises](https://github.com/danieljharvey/functional-programming-is-boring/blob/master/src/lesson1-option.ts)
 
 ### Lesson 2 - Either
 

slides/complexity.md

@@ -1,9 +1,9 @@
-# Cardinality 
+# Cardinality
 
 ## Measuring complexity
 
 - Reducing complexity is good, and so it's helpful to have a way of measuring
-  it. 
+  it.
 
 - Look at this simple type:
 
@@ -19,39 +19,41 @@ type ManyOptions = {
 - What about now?
 
 ```typescript
-type SlightlyLessOptions = {
-  type: 'electricity',
-  eco7: boolean
-} | {
-  type: 'gas'
-}
+type SlightlyLessOptions =
+  | {
+      type: 'electricity'
+      eco7: boolean
+    }
+  | {
+      type: 'gas'
+    }
 ```
 
 - A small change reduces the number of options, and thus the number of code
   paths needed to deal with it.
 
-- Although it's trivial now, as a data type grows it becomes more significant. 
+- Although it's trivial now, as a data type grows it becomes more significant.
 
 ```typescript
 type ContrivedTariff = {
-  type: 'electricity' | 'gas',
+  type: 'electricity' | 'gas'
   eco7?: boolean
   elecReading?: number
   gasReading?: number
-} 
+}
 ```
 
-## How do we measure it? 
+## How do we measure it?
 
-This measure of how many possible values exist in a type is called *cardinality*.
+This measure of how many possible values exist in a type is called _cardinality_.
 
-- It is defined by the first result in a Google search I just did as: 
+- It is defined by the first result in a Google search I just did as:
 
 `the number of elements in a set or other grouping, as a property of that grouping.`
 
 - `Boolean` can be `true` or `false`
 
-- so...? 
+- so...?
 
 - Yes, indeed, `2`.
 
@@ -61,29 +63,29 @@ This measure of how many possible values exist in a type is called *cardinality*
 
 - I mean `3`. Lolle.
 
-- The cardinality of `string` or `number` is very large indeed 
+- The cardinality of `string` or `number` is very large indeed
 
-- How does this relate to our new friends `Either` and `Maybe`?
+- How does this relate to our new friends `Either` and `Option`?
 
 ## Algebraic Data Types
 
-- So `Maybe` and `Either` are both examples of `Algebraic Data Types`
+- So `Option` and `Either` are both examples of `Algebraic Data Types`
 
 - More accurately, `sum types`
 
 - (The other kind are `product types`, we'll come to those...)
 
-## Maybe 
+## Option
 
-- `Maybe A` is a `sum type` because it's *cardinality* is 
+- `Option A` is a `sum type` because it's _cardinality_ is
 
 - the sum of `whatever the cardinality of A is` and `1`
 
 - So `A` + `1`, kinda.
 
 - (The `1` is to represent `Nothing`)
 
-- The type `Maybe<boolean>` could have values of either 
+- The type `Option<boolean>` could have values of either
 
 - `Just(true)`
 
@@ -110,14 +112,15 @@ This measure of how many possible values exist in a type is called *cardinality*
 But how does it relate to complexity?
 
 - Bare with me - I swear we're getting to a breakthrough
- 
-## Product types 
+
+## Product types
 
 - `Product types` are the other kind of `Algebraic Data Type` (`ADT`)
 
 - They are way more boring tbh.
 
 - Most Typescript interfaces are `Product types`
+
 ```typescript
 interface Person {
   name: string
@@ -131,17 +134,17 @@ interface Person {
 - (And why wouldn't we? They are broadly supported and it's considered idiomatic
   to do so.)
 
-- (And I'm not writing a thinkpiece named __Javascript Objects Considered Harmful__ or anything)
+- (And I'm not writing a thinkpiece named **Javascript Objects Considered Harmful** or anything)
 
 - (yet)
 
 ## Anyway
 
-- Whilst `sum types` describe `this` *OR* `that`.
+- Whilst `sum types` describe `this` _OR_ `that`.
 
-- `Product types` describe `this` *AND* `that`.
+- `Product types` describe `this` _AND_ `that`.
 
-- So, a `Person` interface is just a nice way of carrying around a `string` *AND* a `number`
+- So, a `Person` interface is just a nice way of carrying around a `string` _AND_ a `number`
 
 ## Tuple
 
@@ -150,27 +153,28 @@ interface Person {
 - A very simple simple product type is `Tuple A B`
 
 - We could represent it like this:
+
 ```typescript
-type Tuple<A,B> = { type: "Tuple", a: A, b: B }
+type Tuple<A, B> = { type: 'Tuple'; a: A; b: B }
 ```
 
-- It is the *dual* of `Either`...
+- It is the _dual_ of `Either`...
 
-- `Either<A,B>` is `A` *+* `B`.
+- `Either<A,B>` is `A` _+_ `B`.
 
-- `Tuple<A,B>` is `A` *x* `B`.
+- `Tuple<A,B>` is `A` _x_ `B`.
 
 - A `Tuple<string,number>` could represent `Person` interface from before as
-  it's their `name` *AND* `age`.
+  it's their `name` _AND_ `age`.
 
-- Whilst `Either<string,number>` could be used to describe a person's `name` *OR*
+- Whilst `Either<string,number>` could be used to describe a person's `name` _OR_
   `age`.
 
 - (I'm not sure why you would do this, admittedly)
 
-- So, knowing that the *cardinality* of `Either<TrafficLights, boolean>` is `5`
+- So, knowing that the _cardinality_ of `Either<TrafficLights, boolean>` is `5`
 
-- What is *cardinality* of `Tuple<TrafficLights, Boolean>`...?
+- What is _cardinality_ of `Tuple<TrafficLights, Boolean>`...?
 
 - .
 
@@ -194,18 +198,22 @@ type Tuple<A,B> = { type: "Tuple", a: A, b: B }
 
 - So wherever you find yourself adding more rows to a type, think
 
-- Will this __REALLY__ always be there?
+- Will this **REALLY** always be there?
 
 - Or can I make it a `sum` instead?
 
-## Extra task time 
+## Extra task time
+
+- Given a constructor for making `Tuple` types:
 
-- Given a constructor for making `Tuple` types: 
 ```typescript
-const tuple = <A,B>(a: A, b: B): Tuple<A,B> =>
-  ({ type: "Tuple", a, b })
+const tuple = <A, B>(a: A, b: B): Tuple<A, B> => ({
+  type: 'Tuple',
+  a,
+  b,
+})
 
-tuple("Horse", 100)
+tuple('Horse', 100)
 // { type: "Tuple", a: "Horse", b: 100 })
 ```
 
@@ -220,4 +228,3 @@ tuple("Horse", 100)
 - `match :: (A -> B -> C) -> Tuple A B -> C`
 
 - Why is implementing `join` or `bind` difficult?
-