3 ms·
I've only done a handful of Haskell tutorial, I mostly do Elixir (and sometimes Erlang) when it comes to FP. Elixir/Erlang is most definitely not pure or side-e
by Xixi 11y ago
I've only done a handful of Haskell tutorial, I mostly do Elixir (and sometimes Erlang) when it comes to FP. Elixir/Erlang is most definitely not pure or side-effect free.
I understand how IO can be made explicit, but I don't understand how it can be made pure. An addition might return `Nothing` if the input is malformed in some way as you say, but 1 + 1 will always return 2. On the other hand IO will return different values all the time. You can certainly make all of that explicit, but if given the same input you get different outputs, isn't that the opposite of "pure"?
I really have to dig into Haskell more...
- fenollp 11y agoFunctional programming isn't about being side-effects free, it's about controlling side effects. You can't write (useful) pure programs, but pure functions.
- dragonwriter 11y ago> I understand how IO can be made explicit, but I don't understand how it can be made pure. Expressions with IO in them do not "do" IO, they declare a composable specification for how IO is to be done. When one of those expressions is "main", the runtime will do that specified IO (which, in the case of programs with nontrivial IO, will itself be composed of several other IO actions) when the program is run. All the expressions containing IO are pure, because what they return every time they are called is the same specification of an IO action comprised of lower-level IO actions. Values in the IO monad aren't the results of performing IO, they are procedures, in the imperative sense, that do IO. The "main" function of a Haskell program -- because it returns a value in that monad -- returns such a procedure, which the runtime executes.
- Xixi 11y agoThanks for this clear explanation, the IO monad is starting to make sense to me now...