Am Montag, 1. August 2005 22:38 schrieb Tomasz Zielonka:
On Thu, Jul 28, 2005 at 08:01:17PM +0200, Diego y tal wrote: [...]
but.. is it normal that we have to think about this "problem" when programming?
You just have to know, which functions mix laziness and side-effects by using unsafeInterleaveIO (readFile, getContents, hGetContents).
Well, it is important to note that implementations of readFile etc. should use locking according to the System.IO documentation. If they do so, evaluation order may have an impact on the question whether opening a file fails or not but it changing the order of evaluation cannot change the data read from or written to a file anymore. In Diego's example, removing print x wouldn't result in different data written to the file but in a failure at the first writeFile as I already pointed out. Now, if we implement readFile so that the same file cannot be opened for writing by the same program anymore then changing the evaluation order can no longer change the effect of the program. This would be similar to Clean's I/O library where there are the sf* file reading functions where sfopen has exactly this effect of forbidding opening the same file for writing until the end of the program.
[...]
Best regards, Wolfgang