As preparation for my type checking workshop I've printed in a nice form four papers I think give you a better overview of the field. Here's a thread with them 🧵 "OutsideIn(X): modular type inference with local assumptions" () describes the constraint-based approach to typing. It builds quite slowly, but ends up with a Haskell-like language which even includes GADTs.simon.peytonjones.org/assets/pdfs/ou…

A small thread with some of my thoughts re. effects, continuations, and "direct style". 🧵 One of the ideas floating in the FP community is "declaring and handling effects", where "effect" ranges from "throws an error" to "uses something from the context". In essence, what we want to do is to control the execution of a piece of code from the outside.

It's time to announce that in this month-between-jobs I'm working on a NEW BOOK! 📖

📚 Haskell (Almost) Standard Libraries 📚

A walk through the main libraries used by the Haskell community for "common" tasks. Think of data structures, serialization, network... This is the current Table of Contents. Half of the book is already written ✍️, the parts marked with TODO are yet to be finished (or even started).

I'm aiming for a first beta release by the end of the month, and have it finished around April.

I have this idea of "Formal DDD" in my mind since some time ago. So I've thought "let's run it throught Twitter to see what people think" The core idea is to ensure that your "core domain" is really well-described, also in a way that can be formally verified. To do so you keep a model in Alloy/TLA+, which describes every invariant that the core domain should satisfy.

Here is my take on teaching #Haskell and what should we do better. Please engage in helpful criticism and discussion 😀

So, thread below 👇 For me, "functional style" requires of these three things:
- focus on immutability and separation of side-effects,
- higher-order functions,
- data types with support for sums/choices.
Everything but the last point is available in many mainstreams languages *now*.