This is similar to the "null object pattern" in OOP, albeit lacking polymorphism. Since we can't designate the "null struct" as const, we must find an alternative method to prevent writes to it. The use of that `read_only` macro is pretty clever.
This was a great read, for high productivity stuff I agree with everything and its a philosophy I started following since using C/Odin a lot more. Although, I think FP and the pursuit to use type systems to try to make invalid state irrepresentable when working with a lot of people who may or may not be competent, has its place.
This was a great write up! sometimes I forget how different to popular "practices" the fact based approach to programming is. The combinatoric explosion has been a major pain in my C development, but these approaches will help a lot.
I wonder how do you handle errors in a function returning Node* which should be writable? Also how do you handle nil pointers during, say, depth-first search. You still need to check for sentinel values, be it null pointer or preallocated nil pointer?
Functional programming expresses this idea through a `Maybe` / `Option` type. (Or C++ std::optional). Here's a nice writeup of this same idea of "Separate code that checks for presence from code that calculates values": https://thoughtbot.com/blog/problem-solving-with-maybe
Great article packed with good information as always.
This is similar to the "null object pattern" in OOP, albeit lacking polymorphism. Since we can't designate the "null struct" as const, we must find an alternative method to prevent writes to it. The use of that `read_only` macro is pretty clever.
Thanks for the article!
But how do you do "per_thread" globals in C in a portable way? I only know of __thread but it doesn't seem portable or even part of the standard.
If you have a custom macro, I'd love a peek :)
This was a great read, for high productivity stuff I agree with everything and its a philosophy I started following since using C/Odin a lot more. Although, I think FP and the pursuit to use type systems to try to make invalid state irrepresentable when working with a lot of people who may or may not be competent, has its place.
This was a great write up! sometimes I forget how different to popular "practices" the fact based approach to programming is. The combinatoric explosion has been a major pain in my C development, but these approaches will help a lot.
I wonder how do you handle errors in a function returning Node* which should be writable? Also how do you handle nil pointers during, say, depth-first search. You still need to check for sentinel values, be it null pointer or preallocated nil pointer?
Functional programming expresses this idea through a `Maybe` / `Option` type. (Or C++ std::optional). Here's a nice writeup of this same idea of "Separate code that checks for presence from code that calculates values": https://thoughtbot.com/blog/problem-solving-with-maybe