While true (and perhaps is another minor enlightenment, that the parameters of a type signature do not need to actually correspond to any runtime values, which

While true (and perhaps is another minor enlightenment, that the parameters of a type signature do not need to actually correspond to any runtime values, which the article talks about in its own way later), I do think this is an extremely important point that I appreciate the article bringing up and want to hammer home myself. I often see the sentiment on HN and other programming forums that the "magic of Haskell's mysterious and arcane type system with the bogeyman of inscrutable category theory and monads" (to exaggerate just a tad) prevents you from mixing pure and non-pure code in Haskell. That's not what's going on. It's just a clever choice by the standard library to not export certain functions that unwrap a type (or at least hide it behind a function with the word unsafe in it), a trick that is used by any language that has support for private and public functions. Indeed this exact same thing can be replicated by any language that is expression-focused and has support for immutable bindings. Just modify your standard library to wrap everything side-effectful in an IO type and don't let users unwrap that.