is GHC's implementation of Haskell semantically broken?

No, using unsafe... doesn't count:

Using unsafeCoerce is clearly a rule-breaking move, so to answer the question "Does this really count?": no, it doesn't count. unsafe is the warning that all sorts of stuff breaks, including semantics:

isGood :: a -> Bool
isGood x = unsafePerformIO . fmap read $ readFile "I_feel_like_it.txt"

> isGood '4'
True
> isGood '4'
False

Yikes! Broken semantics according to the Haskell report. Oh, no, wait, I used unsafe... . I was warned.

The main problem is using unsafeCoerce , with which you can turn anything into anything else. It's as bad as typecasts in imperative programming, so all type safety has gone out of the window.

You're catch ing an IOException, not a pure error (⊥).

To use catch, you've converted the pure error undefined to an IO Exception. The IO monad is deceptively simple, and the error handling semantics don't require the use of ⊥. Think of it as like a monad transformer including an error-handling Either at some level.

The link with the halting problem is completely spurious

We don't need any unsafe features of any programming language to cause this sort of distinguishing between non-termination and error.

Imagine two programs. One program Char -> IO () that outputs the character, the other which writes the output of the first to a file, then compares that file with the string "*** Exception: Prelude.undefined" , and finds its length. We can run the first one with input undefined or with input 'c' . The first is ⊥, the second is normal termination.

Yikes! We've solved the halting problem by distinguishing between undefined and non-termination. Oh no, wait, no, we've actually only distinguished between undefined and termination. If we run the two programs on the input non_terminating where non_terminating = head.show.length $ [1..] , we find the second one doesn't terminate, because the first one doesn't. In fact our second program fails to solve the halting problem, because it itself does not terminate.

A solution to the halting problem would be more like having a total function halts :: (a -> IO ()) -> a -> Bool that always terminates with the output True if the given function terminates with input a , and False if it never terminates. You're impossibly far from that when you distinguish between undefined and error "user-defined error" , which is what your code does.

Thus all your references to the halting problem are confusing deciding whether one program terminates with deciding whether any program terminates. It fails to draw any conclusion if you use the input non-terminating above instead of undefined ; it's already a big stretch semantically to call that distinguishing between non-termination and undefined , and it's nonsense to call it a solution to the halting problem.

The problem isn't a huge semantic issue

Essentially all your code is able to do is determine whether your error value was produced using undefined or some other error producing function. The semantic issue there is that both undefined and error "not defined with undefined" have the semantic value ⊥, but you can distinguish between them. OK, that's not very clean theoretically, but having different outputs on different causes for ⊥ is so useful for debugging that it'd be crazy to enforce a common response to the value ⊥, because it would have to be always non-termination to be completely correct.

The result would be that any program with any bug would be obliged to go into an infinite output-free loop when it had an error. This is taking theoretical niceness to the point of deep unhelpfulness. Much better is to print *** Exception: Prelude.undefined or Error: ungrokable wibbles or other helpful, descriptive error messages.

To be at all helpful in a crisis, any programming language has to sacrifice your desire to have every ⊥ behave the same as each other. Distinguishing between different ⊥s isn't theoretically lovely, but it would stupid to not do this in practice.

If a programming language theorist calls that a severe semantic problem, they should be teased for living in a world where program-freeze/non-termination is always the best outcome for invalid input.