Editing Maintaining laziness (section)

== Lazy input and output ==

[https://arxiv.org/pdf/1907.11354 Like in SWI-Prolog], lists can can be used for lazy I/O.
So for ordinary functions, lazily writing data to output is usually not a problem.
But in Haskell, lazily reading data as input can require some sort of internal I/O hack and thus caution.
Consider the simple program:
<haskell>
readFile "source" >>= writeFile "target"
</haskell>

which copies the file <code>source</code> to the file <code>target</code> with constant memory consumption, since <hask>readFile</hask> reads the data lazily and <hask>writeFile</hask> writes it as it comes in.
However it fails badly, when a file is to be updated in-place:
<haskell>
readFile "text" >>= writeFile "text" . map toUpper
</haskell>

This would only work if <hask>readFile</hask> was strict, that is it would read the file contents in full to memory before passing that data (as a <code>String</code>) back to its caller.

The function <hask>readFile</hask> needs certain hacks:
* The function <hask>unsafeInterleaveIO</hask> is needed for deferring the calls to <hask>hGetChar</hask> until the characters are actually needed.
* Exceptions, that occur while reading the file, are raised in the code that writes the result of processing the file content to somewhere i.e. the exceptions produced by <hask>readFile</hask> can occur in code that has nothing to do with file reading and there is no warning, that they might occur there. The [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/explicit-exception explicit exception] package can also help here, by making the reason for the stop of the file read explicit. Exceptions must still be handled in code, that does not read the file, but the fact that they are explicit helps you to not forget it.
* The file must be closed after it is no longer needed. The documentation says, that the file is put into a semi-closed state. One possibility is that weak references are used, allowing the [[garbage collector]] close the file, once all other references to data in the file have been revoked. However, the garbage collector never works immediately, but in phases. It may be that the file remains open for a long time, maybe until the program exits. The <hask>Data.ByteString.Lazy.readFile</hask> function explicitly closes the file after the last byte is read. The advantage is, that the file is closed immediately. The disadvantage is, that the file is not closed at all, when not all bytes are read. E.g. if a parser encounters a parse error, it has to read the rest of the file anyway, in order to get it closed.

A function that handles the closing of the file for you is <hask>System.IO.withFile</hask>.
You can use it like this:
<haskell>
withFile "source" ReadMode $ \h ->
   hGetLine h >>= putStrLn
</haskell>

After the actions inside the <hask>withFile</hask> call, the file is closed.
However this is dangerous:
* If you attempt to lazily read contents from the file out of <hask>withFile</hask>, the file is closed before the data is actually read.

Thus, although <hask>withFile "source" ReadMode hGetContents</hask> looks like <hask>readFile</hask>, it is very different: it does not work.

How can you implement a function like <hask>hGetContents</hask> by yourselves?
You need to call <hask>hGetChar</hask> in a lazy way.
This is achieved by <hask>unsafeInterleaveIO</hask>.
However, calling <hask>unsafeInterleaveIO hGetChar</hask> many times would not work,
because the order must be preserved.
For example, in:
<haskell>
hGetContents h >>= putStrLn . drop 10
</haskell>

the first ten characters from the file are not needed,
but <hask>hGetChar</hask> must be called for the first 10 characters anyway in order to increment the file position.
This is achieved by not calling <hask>unsafeInterleaveIO</hask> on <hask>hGetChar</hask> but on the list constructor.
The implementation of <hask>hGetContents</hask> resembles:
<haskell>
hGetContents h =
   let go = unsafeInterleaveIO $ liftM2 (:) (hGetChar h) go
   in  go
</haskell>

In contrast to the standard <hask>hGetContents</hask>, this implementation does not close the file
(by the way, it does even not handle the end of the file), but the advantage of not relying on some automatism to close the file somewhen is, that you can close the file immediately after you stopped processing its content.
The disadvantage is that you must not forget to close the file and must do it only once.

So far we have only considered lazy reading.
It might also be necessary to trigger write actions when fetching data.
Consider a server-client interaction, where data can only be read, when a request was sent before.
It would be useful if the request is triggered by reading the result from the server.
Such interactions can be programmed using the {{HackagePackage|id=lazyio}} package.