You would then need a monad to evaluate the things you're attempting to log. And at that point you have a monad, so you can log as usual?
You would then need a monad to evaluate the things you're attempting to log. And at that point you have a monad, so you can log as usual?
Monads and side-effects aren't intrinsically related. Simplifying, a monad is something with flatMap() - in JavaScript, Array and Promise are monads (kinda). What flatMap() gives you is the ability to chain things, which is useful to sequence side-effects so that they can be performed by a machine in a given order. That's why IO and Eff are monads.
It doesn't really matter if you made a horrible uncomputable mistake deep inside a pure function, if you either discard or never use that mistake you would never notice it happened.
For example, nixpkgs (in nixlang) for sure isn't "strict pure FP" - you can do effects whenever you want - but will often have uncomputable evaluations in it. And you will only notice they're uncomputable evaluations when you try to use them. There's even a warning left for future wanderers for that:
### Evaluating the entire Nixpkgs naively will fail, make failure fast
AAAAAASomeThingsFailToEvaluate = throw ''
Please be informed that this pseudo-package is not the only part of
Nixpkgs that fails to evaluate. You should not evaluate entire Nixpkgs
without some special measures to handle failing packages, like those taken
by Hydra.
'';
I see that I formulated my thesis badly, conflating strict evaluation with monads, when as you pointed out they're not strictly related.