3 ms·
I'm pretty sure you can move black boxes around in the real world too :) There are definitely sensible things to do with "general IO operations." For example,
by millstone 12y ago
I'm pretty sure you can move black boxes around in the real world too :)
There are definitely sensible things to do with "general IO operations." For example, consider `withArgs`, which replaces argv for the duration of an action. A natural approach is to pick through the received action, and replace all calls to `getArgs` with `return tempArgs`. But `withArgs` doesn't work this way because Haskell can't pick apart IO actions. Instead it uses a nasty FFI to modify a global. (It doesn't even look thread-safe: I'll bet withArgs "leaks" into other threads.)
It's also overbroad: IO encapsulates "real world" computations like deleting files, but also basic operations like getting argv! I'd argue it's a failure of Haskell that the type system does not distinguish between a function that erases your hard drive and a function that gets your command line arguments.
- pestaa 12y agoYou either enforce 100% purity, or your language is not pure. Haskell chose to walk the former path. In that case reading global state needs to happen in the IO monad even if it is reading a couple of command line arguments. Though I completely agree it is nasty to change them in runtime, it is also assumed you know what you're doing when you tinker with them (cross-thread implications included.) To a Haskell program, command line arguments are exactly the same outer world as your super important files.