updates
This commit is contained in:
parent
9dee43b1ec
commit
94dee13329
5 changed files with 45 additions and 2 deletions
|
@ -1,7 +1,13 @@
|
|||
:PROPERTIES:
|
||||
:ID: 67dab4eb-231f-4af0-bf26-b3cf6d83f9a3
|
||||
:ROAM_ALIASES: "Algebraic Data Types are composable"
|
||||
:END:
|
||||
#+title: Algebraic Data Types are composable
|
||||
#+title: Algebraic Data Types
|
||||
|
||||
Algebraic Data Types are types built by composing other types. This is done in
|
||||
one of two ways:
|
||||
- Product Types :: Type T_1 /and/ T_2 /and/ T_n
|
||||
- Sum Types :: Type T_1 /or/ T_2 /or/ T_n
|
||||
|
||||
Because ADTs are separate from behavior, it's easy to combine them together to
|
||||
make more complex types.
|
||||
|
|
|
@ -4,5 +4,5 @@
|
|||
#+title: Monad
|
||||
|
||||
#+begin_quote
|
||||
A monad is just a monoid in the category of endofunctors.
|
||||
A monad is just a [[id:434ee61c-4461-424f-8dba-5c86ddb06c3c][monoid]] in the category of endofunctors.
|
||||
#+end_quote
|
||||
|
|
7
20220312165500-semigroup.org
Normal file
7
20220312165500-semigroup.org
Normal file
|
@ -0,0 +1,7 @@
|
|||
:PROPERTIES:
|
||||
:ID: b22a1c70-02a7-49ce-b5e7-407f1064cd0c
|
||||
:END:
|
||||
#+title: Semigroup
|
||||
|
||||
A category of types such that two values of the type can be combined
|
||||
associatively to create a new value of the same type.
|
11
20220312165629-monoid.org
Normal file
11
20220312165629-monoid.org
Normal file
|
@ -0,0 +1,11 @@
|
|||
:PROPERTIES:
|
||||
:ID: 434ee61c-4461-424f-8dba-5c86ddb06c3c
|
||||
:END:
|
||||
#+title: Monoid
|
||||
|
||||
A [[id:b22a1c70-02a7-49ce-b5e7-407f1064cd0c][Semigroup]] with an identity value.
|
||||
|
||||
* Examples
|
||||
- List :: Combined with =append=, identity value is the empty list (=[]=)
|
||||
- Number Addition :: Combined with =+=, identity value is =0=
|
||||
- Number Multiplication :: Combined with =*=, identity value is =1=
|
|
@ -4,6 +4,7 @@
|
|||
:END:
|
||||
#+title: Notes on Will Kurt, Get Programming with Haskell
|
||||
|
||||
* [[id:68cedf67-0f59-4a06-9344-77d946129653][Functional Programming]]
|
||||
#+begin_quote
|
||||
John Backus, who led the team that created Fortran, asked in his Turing Award
|
||||
lecture, “Can programming be liberated from the von Neumann style?”
|
||||
|
@ -12,5 +13,23 @@ This question leads to the second way to understand programming, which is the
|
|||
subject of the first unit in this book. [[id:68cedf67-0f59-4a06-9344-77d946129653][Functional programming]] attempts to
|
||||
liberate programming from the von Neumann style.
|
||||
#+end_quote
|
||||
* [[id:67dab4eb-231f-4af0-bf26-b3cf6d83f9a3][Algebraic Data Types]]
|
||||
#+begin_quote
|
||||
The big problem is that you want a single type that represents both vinyl
|
||||
records and books so you can make a searchable inventory. Because you can
|
||||
compose types only by /and/, you need to develop an abstraction that describes
|
||||
everything that records and books have in common. You’ll then implement only the
|
||||
differences in the separate classes. This is the fundamental idea behind
|
||||
/inheritance/.
|
||||
#+end_quote
|
||||
|
||||
#+begin_quote
|
||||
In theory, creating object hierarchies is elegant and captures an abstraction
|
||||
about how everything in the world is interrelated. In practice, creating even
|
||||
trivial object hierar- chies is riddled with design challenges. The root of all
|
||||
these challenges is that the only way to combine types in most languages is with
|
||||
an /and/. This forces you to start from extreme abstraction and move downward.
|
||||
Unfortunately, real life is full of strange edge cases that make this much more
|
||||
complicated than you’d typically want.
|
||||
#+end_quote
|
||||
#+print_bibliography:
|
||||
|
|
Loading…
Reference in a new issue