16

What does exactly make reading from the process memory a pure operation? Suppose I created an array of 100 integers in the global memory and then took the 42th element of this array. It is not a side effect, right? So why is reading the same array of 100 integers from a file a side-effect?

  • 5
    consider editing to explain what makes you think that reading the array of 100 integers from a file is a side-effect, as well as what does "pure operation" mean to you – gnat Oct 8 '14 at 10:20
  • 3
    @gnat Because it is I/O and I/O is a side-effect – ZhekaKozlov Oct 8 '14 at 10:24
  • 3
    what makes you think that I/O is a side-effect? consider edit]ing to explain that to question readers. On a more general note, sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask – gnat Oct 8 '14 at 10:26
  • 22
    @gnat I/O is a side effect, period. It's one of the classic examples. We're not Wikipedia, we don't need citations for folk knowledge. If you think something can be improved about the question, say it outright rather than going through this straw man. – user7043 Oct 8 '14 at 10:41
  • 7
    'O' is a side effect. 'I' is only a side effect if doing the 'I' changes the state of what you are doing 'I' from. Which is true for certain memory mapped I/O things but is unlikely to be the case for a normal file. – Tom Tanner Oct 8 '14 at 12:27
27

If the memory you access can change, then it is indeed a side effect.

For example, in Haskell, the function to access a mutable array (IOArray) has type

Ix i => IOArray i e -> i -> IO e

(slightly simplified for our purposes). While accessing an immutable array has type

Ix i => Array i e -> i -> e

The first version returns something of type IO e which means it has I/O side effects. The second version simply returns an element of type e without any side effects.

In case of accessing a file, you simply cannot know at compile time whether the file will ever change during a run of the program. Therefore, you have to always treat it as an operation with potential side effects.

  • 4
    Well, with files you simply cannot be absolutely sure. – ftr Oct 8 '14 at 11:03
  • 2
    You can never be sure, but more important: the compiler cannot be sure. In addition, your file system might get corrupted or your hard disk might disconnect while you're reading the file. – Tobias Brandt Oct 8 '14 at 11:35
  • 5
    Those aren't side effects of the program, they're side effects of other things. Memory's not side-effect-free, either, since an alpha particle or stray neutron can flip a bit and result in a change to the array. – Blrfl Oct 8 '14 at 11:46
  • 3
    @Blrfl That's a good point, however I don't think the two are comparable. Memory corruption is not something you can deal with because it can affect the program data and instructions in an arbitrary way. If it happens, the only thing to do is to terminate the program (and probably the OS). On the other hand, a read error due to file system corruption is something you have to expect and be able to handle. It's an inherent part of dealing with files. – Tobias Brandt Oct 8 '14 at 12:04
  • 2
    You're getting out of the realm of side effects and into error detection and handling, which is an entirely different discussion. The question of side effects is one of whether or not an operation has any effects on anything else, not whether or or not the result of the operation can be influenced by external factors. – Blrfl Oct 8 '14 at 12:15
10

In computer science, a function or expression is said to have a side effect if, in addition to returning a value, it also modifies some state or has an observable interaction with calling functions or the outside world. Reading from a file is an observable interaction with the outside world. It meets the definition of side effect. Reading the 42nd element from global memory would be a side effect as well unless your array is a constant because it would be an observable interaction with other functions that may modify the array.

2

If you have a shared file handle then reading a file will move that file handle to the position where you have read, and will leave it at that position.

If you have two threads with separate file handles to the same file, reading from one will have no noticeable side effect on the other.

However in both these cases, memory reading and file reading, there could be a hidden side effect of operator system caching.

0

Reading from memory does not influence other functions and is therefore side-effect-free. Reading from a file will typically move the file's position pointer, so that when you read again you read the data after what you have already read, so one read function changes the result of other read functions, which is a side effect. If you instead open, read and close a file in one go than this side effect disappears, but that is not feasible for big files. Additionally, depending on how you open the file, it may become locked after opening it, so the first try to open and read the file succeeds while following tries will fail with a File Already Open error, which again is a side effect.

Creating a side-effect-free reading function that reads the file in one go and allows multiple reads at the same time is difficult because there are file writing functions which get influenced by the reading function and getting rid of file writing functions is again not feasible.

  • 1
    You could have side-effect free reading from a file if the file did not change and you turned the file into a stream (lazy list). – Giorgio Oct 8 '14 at 10:56
  • 2
    Reaching out to the OS for a file that is not under your control is a side effect. Only if you could control the mutability of the file (and maybe sequence mutating operations on it … via the IO monad?) you could make a side-effect-free function for reading. – Bergi Oct 8 '14 at 14:36
0

Reading from a stream is a side effect already because the result of functions such as isEOF may return different result after the read than before the read.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.