Compare commits

...

2 Commits

Author SHA1 Message Date
8754d3537a Answered questions 2025-03-21 17:50:36 +01:00
37064bc265 Writeups readme 2025-03-21 17:50:30 +01:00
2 changed files with 52 additions and 0 deletions

View File

@ -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 doesnt 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]: [HindleyMilner type inference](https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system)

21
writeups/README.md Normal file
View 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