How can IO cause side effects in Functional Programming? [duplicate]

Question

This question already has answers here:

Why is reading from memory not a side-effect but reading from a file is? (5 answers)

Closed 5 years ago.

Whenever I read about Haskell, I find that IO can cause side effects.

But I do not understand how it would do it?

Do we mean that we are writing to a file from one lazy sequence and another lazy sequence is reading from same file?

Is that the only possibility or is there something fundamentally deep?

Answer 1

The Haskell optimizer is allowed to freely manipulate calls to pure functions as long as the result remains the same. For example, if it can see that you are calling sqrt on the same number 100 times, it can cache the returned value and only call it once. If it can see that you never actually use the result of that function, it can choose to not call it at all.

These things can't be done with IO. If you read from stdin 100 times, you wouldn't want to optimizer to cache the first read and reuse that value 99 more times. If you write to the console and discard the return value (because you don't actually care about the return value of putStrLn) you wouldn't want the optimizer to remove the function call altogether.

That's the meaning of side effects - not from the programmer's point of view (the programmer clearly meant for these things to happen) but from the optimizer's point of view.

Answer 2

Simplest possible example: printing "Hello, world!" changes the state of the system, because the console now displays "Hello, world!", and earlier it didn't. Not only have you changed the state, it's actually impossible to change it back, since you can't un-get characters from a terminal! That's about the most serious side effect possible.

Answer 3

I think the problem is that you are a bit unclear on what is meant by a side effect. In a pure function with no side effects, the function gives a result that is a direct result of the input and nothing else. In a function with side effects, the function depends on or changes the state of the outside world. So if you have a function like square(x), then that is a pure function. On the other hand, if you have function like launch_the_missiles(), then that has a very real side effect (or for a more mundane example, print a page).

So doing IO changes the state of the world, that is the side effect

Answer 4

It sounds like you don't know the CS definition of a side effect. A function has a side effect if it has any observable interaction with the system outside of that function. Therefore output is always a side effect, you can observe a change in the hard drive, network, console where ever your output went. Input is similarly a side effect, because it has an effect on the computation happening in the function, and may cause an effect in the external system i.e. reading from a console or socket.

Answer 5

Side effects mean that, after every IO operation, the state of the system may be changed. Haskell provides a clear divide pure Haskell code and IO code.

See : http://learnyouahaskell.com/input-and-output#hello-world ;

from the book: "In Haskell, a function can't change some state, like changing the contents of a variable (when a function changes state, we say that the function has side-effects). "

Answer 6

Did you ever hear this aphorism?

No man can step in the same river twice. For the second time, it is not the same river, and he is not the same man.

Imagine one of your functions writes a 1 to /dev/ttyusb0. In UNIX, this is "just a file", but in real life, this is actually the name of a microcontroller, and by writing a 1 it activates a bread-slicing machine and slices 500 loaves of pumpernickel. Writing a 1 the first time caused 500 loaves of pumpernickel to go from the "unsliced" state to the "sliced" state. Sending another 1 does not have this effect (because you can't go back to "unsliced"!). It's not the same river.

Imagine another of your functions reads some data from a stream. If it was a static file perhaps you could read it twice and get the same results, but if instead your stream is a data buffer from (yet another) microcontroller (this one is monitoring the baking temperature), then reading the value over and over again will give different results as the oven heats up or cools down. He's not the same man.