19

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?

ZhekaKozlov
  • 311
  • 2
  • 7
  • 5
    consider [edit]ing 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 08 '14 at 10:20
  • 3
    @gnat Because it is I/O and I/O is a side-effect – ZhekaKozlov Oct 08 '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](http://meta.programmers.stackexchange.com/questions/6559/why-is-research-important). 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 [ask] – gnat Oct 08 '14 at 10:26
  • I don't think at all. I just paraphrase things that I have read from books. For example, Function programming in Scala says that reading from or writing to a file is a side-effect. – ZhekaKozlov Oct 08 '14 at 10:41
  • 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. –  Oct 08 '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 08 '14 at 12:27
  • Reading from the file has side effects such as changing the last access time on the file, access permission checks, and so on. Reading from memory assigned to the process does not have those side effects. Reading from shared memory will have some side effects, but generally not as many as from a file. – mpez0 Oct 08 '14 at 14:54
  • If someone wanted to implement a version of Haskell that did its own memory paging but kept the same public semantics then it would be side effect free (technically the files would have last access time modified and such, but that would not be exposed to the programmer directly) for the purpose of writing programs. The *implementation* of pure functional languages may, and do, have side effects. If as a programmer you are accessing a file *at the level of the program itself* you are dealing with a concept, files, that conceptually includes side effects. – psr Oct 08 '14 at 17:06
  • @delnan did you read the question? it asks about input only, if this is as apparently a side effect as output, I would be happy to learn – gnat Oct 10 '14 at 18:40

5 Answers5

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.

Tobias Brandt
  • 543
  • 4
  • 10
  • So, if I'm absolutely sure that a file will always contain the same data (e.g. an icon that never changes) then reading from it will no more be a side-effect? – ZhekaKozlov Oct 08 '14 at 10:48
  • 4
    Well, with files you simply cannot be absolutely sure. – ftr Oct 08 '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 08 '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 08 '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 08 '14 at 12:04
  • 3
    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 08 '14 at 12:15
  • 1
    @Blrfl: You need to specify "anything". We need to draw a line somewhere, otherwise a *pure* functions is only a concept of abstract mathematics that cannot be evaluated on actual hardware :-) – Bergi Oct 08 '14 at 14:42
  • @Blrfl Side effects aren't just effects on global state. It also includes being effected by global state. http://en.wikipedia.org/wiki/Side_effect_(computer_science) – stonemetal Oct 08 '14 at 14:45
  • @stonemetal: The Wikipedia article you cite says that if a function _f_ has some impact on the state of something, then _f_ has side effects. It does not say that side effects of _f_ influencing the behavior of function _g_ which has no side effects of its own imbues side effects on _g_. – Blrfl Oct 08 '14 at 15:11
  • I think in C or C++ or Assembler languages or other low-level programming languages reading from memory may be a side effect, as these languages can and often do change memory. They are used to build operating systems, after all. – trysis Oct 08 '14 at 15:14
  • @Blrfl Nope, their list of example side effects includes _call other side-effecting functions_ side effects "taint" the whole call stack. Further more any function that requires a knowledge of state external to the function call to understand its output is a function that has side effects. – stonemetal Oct 08 '14 at 15:33
  • 1
    @orionll Reading from a file can cause a change to its access time, if enabled for that filesystem. That's a (small) side-effect, and as hinted above, it's not something that the compiler is capable of knowing about beforehand – Izkata Oct 08 '14 at 18:32
  • 1
    @TobiasBrandt `"your file system might get corrupted or your hard disk might disconnect while you're reading the file"` - Your RAM can not? – mip Dec 10 '14 at 21:54
  • @doc See my previous comment: http://programmers.stackexchange.com/questions/258431/why-is-reading-from-memory-not-a-side-effect-but-reading-from-a-file-is/258433?noredirect=1#comment523739_258433 – Tobias Brandt Dec 11 '14 at 11:49
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.

stonemetal
  • 3,371
  • 16
  • 17
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.

CashCow
  • 1,610
  • 13
  • 16
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.

nwp
  • 194
  • 7
  • 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 08 '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 08 '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.

Hagen von Eitzen
  • 235
  • 1
  • 6