> How can parallel untracked mutations of untracked state be better for engineers? What is untracked? Is unsafePerformIO (printLn ...) tracked? What is t

> How can parallel untracked mutations of untracked state be better for engineers? What is untracked? Is unsafePerformIO (printLn ...) tracked? What is tracked? Is foo :: IO () thread-safe? Maybe, maybe not. What meaningful information does this signature says to me? That it does some IO? That's an extremely useless information, especially if most of your code is IO something. What granularity does IO have? Does foo :: IO () throws any exceptions? Maybe, maybe not. The need for effect tracking for writing correct programs is way overstated by some Haskell programmers. It's usually much more prudent to write DSLs which hide effects like variable mutations and logging, than expose them. For example you can start your program with a pure correct-by-construction core DSL, and then add logging, mutable variables where needed underneath the DSL's terms without breaking the semantics of the DSL. With effect tracking you are doomed to either reinvent custom effects to be able to switch interpreters painlessly, or you'll need to break the DSL by the addition of effects. Neither is prudent in real world, neither gives more value than takes. What is really funny is that some Haskell programmed believe that logging should be tracked, but allocation apparently should not (yes, it's a side effect). Where in fact all the "effects" are need to be tracked only when they are meaningful, i.e. when they are part of our DSL's semantics, and not some hidden part of the interpreter I don't need to know about. Imagine a theorem prover function which creates a conjunction of two terms: val conj : term -> term -> term It doesn't matter if it allocates or logs, at the precision that is interesting to us, it's just a function creating a conjunction of two terms.