> monadic I/O is one of the silliest contortions I've seen (uniqueness types in Mercury and Clean are much easier to work with)
As far as I can see they're all basically the same thing. You enforce sequence by creating a chain of notional "real world" values. I can't say I've used Clean or Mercury extensively, but as far as I can see they just make you pass around that value explicitly. That doesn't really seem like it would be "easier to work with".
> That doesn't really seem like it would be "easier to work with".
1. You dont need monadic versions of all non monadic functions. You dont need fmap, you can just use map.
2. It means there is a well defined order of execution (i.e. The order does not "emerge" as in Haskell, instead it is defined and verified by type system)
It is much much easier to work. In Haskell you feel forcedto separate io from transformation as much as posible. Often you end with either repeating ourself a lot (writing oth mondic as non monadic versions) ir you venture out in monad transformers, which imho is the "goto" of Haskell. (How to turn your code in unreadable unmaintainable spagetti). The cognitive overload is never worth it.
Ps. Uniqueness types are not just about IO. Rust uses them as well. They are about sharing. Haskells needs an IO () type because without a monad it has no defined order of execution, and it cant prevent you from "forking the world" when working with outside references.
If Haskell could prevent you (by using uniqueness) i doubt they would have used monads for IO. (Although they can be usefull in other areas).
As far as I can see they're all basically the same thing. You enforce sequence by creating a chain of notional "real world" values. I can't say I've used Clean or Mercury extensively, but as far as I can see they just make you pass around that value explicitly. That doesn't really seem like it would be "easier to work with".