Why does running GHCi in Windows make it not possible to detect infinite loops?

Question

I'm currently reading "Haskell Programming from first principles" and there is a paragraph in the section about bottom that reads:

Let us examine a few ways by which we can have bottom in our programs:

Prelude> let x = x in x

*** Exception: << loop >>

Here GHCi detected that let x = x in x was never going to return and short-circuited the never-ending computation. This is an exam- ple of bottom because it was never going to return a result. Note that if you’re using a Windows computer, this example may freeze your GHCi and not throw an exception.

My question is: is there anything inherent to Windows that makes it impossible or difficult to detect this loop or is it just specific to the GHC(i) implementation?

Answer 1

The comment seems to be outdated. I can confirm that in GHCi 8.6.4 on Linux, entering this code in an interactive prompt simply hangs.

Moreover, if you take the program:

main = let x = x in x

and compile it with GHC 8.6.4 (again on Linux), then compiled without optimization it hangs, while compiled with -O2 it prints:

Loop: <<loop>>

It doesn't seem to make any difference whether it's compiled threaded or not.

The bottom line is that GHC makes no real guarantees about which infinite loops it may or may not "catch", and this can change from version to version and with different optimization settings, and in interactive versus not interactive code, and might be different from architecture to architecture.

There's nothing inherent to Windows that would prevent this detection process, and no particularly reason why the Windows and Linux versions of a program would behave differently. If the comment was accurate at one point, it was probably some subtle difference in code generation under Windows that led to the difference in observed behavior.