Compare commits
2 Commits
d1531d45d9
...
8754d3537a
Author | SHA1 | Date | |
---|---|---|---|
8754d3537a | |||
37064bc265 |
@ -16,6 +16,7 @@ This is the larger, more general README, which will house the main takeaways/rev
|
|||||||
- [ToC](#toc)
|
- [ToC](#toc)
|
||||||
- [Books and resources](#books-and-resources)
|
- [Books and resources](#books-and-resources)
|
||||||
- [13th of March - Introduction](#13th-of-march---introduction)
|
- [13th of March - Introduction](#13th-of-march---introduction)
|
||||||
|
- [\[16th of March - Deriving types\]](#16th-of-march---deriving-types)
|
||||||
|
|
||||||
# Books and resources
|
# Books and resources
|
||||||
- [Haskell Programming from first principles](http://haskellbook.com/)
|
- [Haskell Programming from first principles](http://haskellbook.com/)
|
||||||
@ -41,6 +42,36 @@ The tree is simply too complex. Linked lists are easy.
|
|||||||
## [16th of March - Deriving types]
|
## [16th of March - Deriving types]
|
||||||
|
|
||||||
> How does one do this systematically?
|
> How does one do this systematically?
|
||||||
|
**Eyeball method:**
|
||||||
|
Looking at the function definition:
|
||||||
|
|
||||||
|
1. Each parameter - what is the type of each parameter?
|
||||||
|
2. Return type - what is the type of the return value?
|
||||||
|
3. If the function calls another function, look at the type of that function.
|
||||||
|
4. Replace concrete types with type variables (a, b, c, etc.)
|
||||||
|
|
||||||
|
**Formal method[^2]:**
|
||||||
|
(on paper)
|
||||||
|
|
||||||
|
1. Write down the type of each argument and subexpression.
|
||||||
|
2. Generate equations for how types relate to each other and apply transitivity (if needed).
|
||||||
|
e.g.
|
||||||
|
$$
|
||||||
|
\begin{align*}
|
||||||
|
f &:: a \to b \to c \\
|
||||||
|
g &:: c \to e \\
|
||||||
|
|
||||||
|
\implies f \circ g &:: a \to b \to e
|
||||||
|
\end{align*}
|
||||||
|
$$
|
||||||
|
3. Solve the equations for the most general type.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
> Lazy and singly-linked lists, what's the relation?
|
> Lazy and singly-linked lists, what's the relation?
|
||||||
|
A lazy list doesn’t compute all elements at once; it only computes elements as you need them.
|
||||||
|
A singly-linked list is naturally great for lazy, because each element points to the next, with the next being a thunk (actual fucking term, meaning a computation that hasn't been evaluated yet[^1]).
|
||||||
|
|
||||||
|
|
||||||
|
[^1]: More generally, a thunk is a subroutine used to inject computation into another subroutine. They delay computation until it is needed. It canonically originates from the verb *think* lmao.
|
||||||
|
[^2]: [Hindley–Milner type inference](https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system)
|
21
writeups/README.md
Normal file
21
writeups/README.md
Normal file
@ -0,0 +1,21 @@
|
|||||||
|
The most significant (prioritized) writeups that I'm working on can be seen in the footer at [confest.im](https://confest.im/blog), but this folder includes every "technical" (and related to the languages described here) writeup I am working on.
|
||||||
|
|
||||||
|
## Ideas and progress
|
||||||
|
Tables concerning the idea, the description and progress of the writeups I am working on.
|
||||||
|
Scale of progress:
|
||||||
|
1. 💡 - Idea stage
|
||||||
|
2. 🚧 - Structuring
|
||||||
|
3. ✏️ - Writing
|
||||||
|
4. ✅ - Finished
|
||||||
|
5. ❌ - Abandoned
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
| Idea | Description | Progress |
|
||||||
|
|------|-------------|----------|
|
||||||
|
| Memory safety | Understanding memory safety from the perspective of a Python developer | 🚧 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
1. The intersection of functional programming and formal verification as an amateur in both
|
||||||
|
## Miscellaneous ideas
|
Loading…
x
Reference in New Issue
Block a user