4 ms·

I love FP, but it always seems a bit disingenuous to claim that it is "pure". Most programs raison d'être is to do IO (that is to say to have side-effects), so

by Xixi 11y ago

I love FP, but it always seems a bit disingenuous to claim that it is "pure". Most programs raison d'être is to do IO (that is to say to have side-effects), so by construction most programs are impure. Bjarne Stroustrup has a say about C++: you don't pay for what you don't use. I like to think about it that way for FP: you don't pay for side effects you don't use.

amelius 11y ago
A program can be both purely functional, and have side-effects. See Haskell, and in particular, see [1]. [1] Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell, Simon Peyton Jones, http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/ http://research.microsoft.com/en-us/um/people/simonpj/papers...
- seanmcdirmid 11y ago
  If an effect is explicit, is it still correct to call it a "side" (implicit) effect?
  - dllthomas 11y ago
    Execution of Haskell has side effects, although they are left unspecified defined by the language. Memory is used, heat is emitted... I agree that explicit effects should not be called "side" effects.
tempodox 11y ago
FP languages are pure to different degrees: Looking at Haskell, each time you actually want to do something (change the state of the world), you are severely beaten with a shower of monads that make side effects hell, even if the specific side effect you need is as trivial (and innocuous) as they come. That is, while you might not pay for side effects you don't use, you are unreasonably overcharged for the side effects you do use, even if they're not worth the trouble (which is why I don't use Haskell). OCaml otoh gives you the choice to turn down the purity a bit (allowing side effects in principle) and even gives you some imperative primitives (viewer discretion is advised). It gives you the benefits of FP without the unreasonable costs that Haskell imposes. I assume other FP languages can do that, too. [Edit: Clarification.]
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- codygman 11y ago
  > each time you actually want to do something (change the state of the world), you are severely beaten with a shower of monads that make side effects hell, even if the specific side effect you need is as trivial (and innocuous) as they come. readFile "/etc/issue" >>= putStrLn Man, I feel so beaten.
  - tempodox 11y ago
    Ha, just put this code into any old deeply nested function that's not already contaminated with the IO monad. Or try to do something that needs two monads at the same time.
    - codygman 11y ago
      > Ha, just put this code into any old deeply nested function that's not already contaminated with the IO monad. Why would I want to do that? I could just pass the filepath to that function if it needed it, or if I want it to log messages I could use the writer monad. > Or try to do something that needs two monads at the same time. Monad transfomers aren't so hard: http://www.cs.virginia.edu/~wh5a/personal/Transformers.pdf http://www.cs.virginia.edu/~wh5a/personal/Transformers.pdf Edit: One of my favorite papers, I believe multiple monads are used in it: http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...
Dewie3 11y ago
I've wanted to get some clarity on the difference between effects and side effects for some time. I think side effects are effects that aren't explicit in the program. So if you have a function with signature `Int -> Int` which also prints something, that is a side effecting program. But if you have a function `Int -> IO Int`, that is not a side effecting function. But it is a function with effects. To complicate things, funprogrammers often like to talk about effects in a broader sense, such as errors and failure. But these effects are often perfectly pure; the effect is some kind of semantic that is layered over some other, existing function. Like an addition that either returns the result, or `Nothing` if the input is malformed in some way. This effect has nothing to do with IO. So what is a non-side effectful function, that does IO? Is it called an "IO effect"? To make things even more complicated, apparently expressions with `IO` in them are pure. That is because it is left to the runtime to actually execute the IO action, or something. At this point, you might feel that they are yanking your chain and using the old "just solve this problem by adding another layer of indirection" (this layer being conceptual). I need to read more on this topic. > Most programs raison d'être is to do IO You can strengthen that; All programs that are to be evaluated need to do IO in order to do anything useful (heating the CPU is not useful). At least I can't think of any counter examples. Surely people like Haskell programmers know this, and the point of IO was never to ban IO in the first place. Just to make it explicit. (Hint: what's the point of having non-strict semantics if you have to assume that any expression may be side-effecting?)
- 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 ago
wz1000 11y ago
Here's an explanation of how IO works in Haskell: http://blog.jle.im/entry/first-class-statements http://blog.jle.im/entry/first-class-statements If you go through it and understand it, you will find that it is completely "pure".
- bobcostas55 11y ago
  Depending on your POV, even C can be said to be purely functional! http://conal.net/blog/posts/the-c-language-is-purely-functional http://conal.net/blog/posts/the-c-language-is-purely-functio...
agumonkey 11y ago
Note that Backus investigated purity long ago (FL) and ended up banging on the IO wall too. I don't get the IO Monad really (I only grasp a tiny bit of it), but I wonder if that's the only way to define IO to fit purely functional evaluation.

by Xixi 11y ago

amelius 11y ago

A program can be both purely functional, and have side-effects. See Haskell, and in particular, see [1]. [1] Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell, Simon Peyton Jones, http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/ http://research.microsoft.com/en-us/um/people/simonpj/papers...

seanmcdirmid 11y ago
If an effect is explicit, is it still correct to call it a "side" (implicit) effect?
- dllthomas 11y ago
  Execution of Haskell has side effects, although they are left unspecified defined by the language. Memory is used, heat is emitted... I agree that explicit effects should not be called "side" effects.

tempodox 11y ago

FP languages are pure to different degrees: Looking at Haskell, each time you actually want to do something (change the state of the world), you are severely beaten with a shower of monads that make side effects hell, even if the specific side effect you need is as trivial (and innocuous) as they come. That is, while you might not pay for side effects you don't use, you are unreasonably overcharged for the side effects you do use, even if they're not worth the trouble (which is why I don't use Haskell). OCaml otoh gives you the choice to turn down the purity a bit (allowing side effects in principle) and even gives you some imperative primitives (viewer discretion is advised). It gives you the benefits of FP without the unreasonable costs that Haskell imposes. I assume other FP languages can do that, too. [Edit: Clarification.]

deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
codygman 11y ago
> each time you actually want to do something (change the state of the world), you are severely beaten with a shower of monads that make side effects hell, even if the specific side effect you need is as trivial (and innocuous) as they come. readFile "/etc/issue" >>= putStrLn Man, I feel so beaten.
- tempodox 11y ago
  Ha, just put this code into any old deeply nested function that's not already contaminated with the IO monad. Or try to do something that needs two monads at the same time.
  - codygman 11y ago
    > Ha, just put this code into any old deeply nested function that's not already contaminated with the IO monad. Why would I want to do that? I could just pass the filepath to that function if it needed it, or if I want it to log messages I could use the writer monad. > Or try to do something that needs two monads at the same time. Monad transfomers aren't so hard: http://www.cs.virginia.edu/~wh5a/personal/Transformers.pdf http://www.cs.virginia.edu/~wh5a/personal/Transformers.pdf Edit: One of my favorite papers, I believe multiple monads are used in it: http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...

Dewie3 11y ago

I've wanted to get some clarity on the difference between effects and side effects for some time. I think side effects are effects that aren't explicit in the program. So if you have a function with signature `Int -> Int` which also prints something, that is a side effecting program. But if you have a function `Int -> IO Int`, that is not a side effecting function. But it is a function with effects. To complicate things, funprogrammers often like to talk about effects in a broader sense, such as errors and failure. But these effects are often perfectly pure; the effect is some kind of semantic that is layered over some other, existing function. Like an addition that either returns the result, or `Nothing` if the input is malformed in some way. This effect has nothing to do with IO. So what is a non-side effectful function, that does IO? Is it called an "IO effect"? To make things even more complicated, apparently expressions with `IO` in them are pure. That is because it is left to the runtime to actually execute the IO action, or something. At this point, you might feel that they are yanking your chain and using the old "just solve this problem by adding another layer of indirection" (this layer being conceptual). I need to read more on this topic. > Most programs raison d'être is to do IO You can strengthen that; All programs that are to be evaluated need to do IO in order to do anything useful (heating the CPU is not useful). At least I can't think of any counter examples. Surely people like Haskell programmers know this, and the point of IO was never to ban IO in the first place. Just to make it explicit. (Hint: what's the point of having non-strict semantics if you have to assume that any expression may be side-effecting?)

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 ago

wz1000 11y ago

Here's an explanation of how IO works in Haskell: http://blog.jle.im/entry/first-class-statements http://blog.jle.im/entry/first-class-statements If you go through it and understand it, you will find that it is completely "pure".

bobcostas55 11y ago
Depending on your POV, even C can be said to be purely functional! http://conal.net/blog/posts/the-c-language-is-purely-functional http://conal.net/blog/posts/the-c-language-is-purely-functio...

agumonkey 11y ago

Note that Backus investigated purity long ago (FL) and ended up banging on the IO wall too. I don't get the IO Monad really (I only grasp a tiny bit of it), but I wonder if that's the only way to define IO to fit purely functional evaluation.