Real-World Composable Error Handling in Reason

If you’ve ever considered handling errors in Reason or OCaml, chances are, you’ve happened upon Vladimir Keleshev’s article. Everybody links to it, so it seems like the way to handle errors. But how does it look in practice?

Type-And-Test Driven Development

I know what type-driven development is (didn’t say I’ve mastered it). I sort of get what is test-driven development, or even red-green-refactor. But can you do both at the same time? If you start with types, is there anything left of the green-red-refactor cycle? Or does that mean you write your tests post factum?

How Not to Introduce ReasonReact to Your Project

Well, actually the reality is not as harsh as the clickbaitey title would make you think. Nothing particularly wrong came out of my introduction of ReasonReact and, by extension, ReasonML to the static build of this very site. The claim that you can introduce Reason & ReasonReact to an existing application one component at a time is entirely true.

Tail-optimized functions in ReasonML

For that mechanism to work, you have to be sure you don’t do anything with the result of the recursive call other than return it as is. That way, you don’t have to return at all. The function instance that is called last evaluates the final result and returns it straight to the original callee.

TIL: Why ReasonML Has No Nullary Functions

“If you don’t provide all of a function’s parameters, you get a new function from the remaining parameters to the result. As a consequence, if you could actually provide no parameters at all, then func() would be the same as func and neither would actually call func.”