How is Data.Void.absurd different from ⊥?
For historical reasons, any Haskell data type (including newtype
) must have at least one constructor.
Hence, to define the Void
in "Haskell98" one needs to rely on type-level recursion newtype Void = Void Void
. There is no (non-bottom) value of this type.
The absurd
function has to rely on (value level) recursion to cope with the "weird" form of the Void
type.
In more modern Haskell, with some GHC extensions, we can define a zero constructor data type, which would lead to a saner definition.
{-# LANGUAGE EmptyDataDecls, EmptyCase #-}
data Void
absurd :: Void -> a
absurd x = case x of { } -- empty case
The case is exhaustive -- it does handle all the constructors of Void
, all zero of them. Hence it is total.
In some other functional languages, like Agda or Coq, a variant of the case above is idiomatic when dealing with empty types like Void
.
Data.Void
moved from the void
package to base
in base version 4.8
(GHC 7.10). If you look at the Cabal file for void
you'll see that it only includes Data.Void
for old base
versions. Now, Void
is defined as chi suggests:
data Void
absurd :: Void -> a
absurd a = case a of {}
which is perfectly valid.
I think the idea behind the old definition is something like this:
Consider the type
data BadVoid = BadVoid BadVoid
This type doesn't get the job done, because it's actually possible to define a non-bottom (coinductive) value with that type:
badVoid = BadVoid badVoid
We can fix that problem by using a strictness annotation, which forces the type to be inductive:
data Void = Void !Void
Under assumptions that may or may not actually hold, but at least morally hold, we can legitimately perform induction on any inductive type. So
spin (Void x) = spin x
will always terminate if, hypothetically, we have something of type Void
.
The final step is replacing the single-strict-constructor datatype with a newtype:
newtype Void = Void Void
This is legitimate too; it's impossible to construct a non-bottom value of this Void
type. The advantage of doing it this way is that it sometimes lets GHC recognize a little code as dead. But it's not a big advantage, and it introduces some unfortunate complications. The definition of spin
, has changed meaning because of the different pattern matching semantics between data
and newtype
. To preserve the meaning precisely, spin
should probably have been written
spin !x = case x of Void x' -> spin x'
(avoiding spin !(Void x)
to skirt a now-fixed bug in the interaction between newtype constructors and bang patterns; but for GHC 7.10 (ha!) this form doesn't actually produce the desired error message because it's "optimized" into an infinite loop) at which point absurd = spin
.
Thankfully, it doesn't actually matter in the end, because the whole old definition is a bit of a silly exercise.