Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A side effect is anything not modeled that can affect the computation.

Input is an obvious example, as it's impossible to predict the value of an input.

Output is less obvious, but there is uncertainty like whether the filesystem is full.

The original Haskell style was to have a World object that was an input to every non-pure function.



Input is an obvious example, as it's impossible to predict the value of an input.

Do you mean this more abstractly or literally? In the example of PacMan, for every frame, the only possible input is nothing, left, right, up, or down. So you are be able to predict it is going to be one of those five, though not which one.


That is unpredictable, but not a side effect. Side effects are changes that are not declared as part of the function parameters.

If you model the controller input as a function parameter, that's just a state argument, and FP can handle it declaratively just fine without having side effects.


> Do you mean this more abstractly or literally?

>> Input is an obvious example, as it's impossible to predict the value of an input.

> though not which one

Literally.


I’m asking as someone not familiar with function programming, so trying to learn, not be pedantic, btw!

So because the possible input is not just a single value, it is not predictable. It doesn’t matter if the input was limited to a set of two values, or infinite, it is literally not predictable so therefore we don’t know the future state of the program?


That’s right! You can consider the user input a source of randomness even if it can only take two values, like heads or tails.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: