Question

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?

Was it helpful?

Solution

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.

OTHER TIPS

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.

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.

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.

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.

Licensed under: CC-BY-SA with attribution
scroll top