Haskell中absurd函数定义里seq的作用是什么？

这个问题挺有意思的，咱们从Void类型的核心特性开始拆解：

首先要明确：Void类型没有任何构造函数——在合法的Haskell代码里，你根本不可能创建出一个Void类型的值。这是理解这个问题的基础。

先贴出你给出的定义方便讨论：

absurd :: Void -> a
absurd a = a `seq` spin a
  where spin (Void b) = spin b

1. 正常合法代码中，用不用seq完全没区别 #

因为你根本传不出一个Void类型的参数给absurd，这个函数永远不会被实际调用。不管你写不写seq，这段代码的实际运行效果都是一样的——永远不会执行到它。

2. 极端场景（unsafe构造Void值）下的细微差异 #

正常情况下没人会这么做，但咱们假设用unsafeCoerce这类手段伪造一个Void值传入absurd：

• 如果去掉seq，直接写absurd a = spin a，spin函数会尝试对伪造的Void值做模式匹配spin (Void b)。但这个值根本不是Void的构造函数（毕竟Void没有构造函数），运行时会触发模式匹配失败的错误（比如程序崩溃）。
• 如果保留seq，a seq spin a会先强制把a求值到弱头范式（WHNF）。因为a是伪造的，求值时运行时会发现它的构造函数不符合Void的定义，会直接触发求值错误，比模式匹配失败的时机更早。

不过这种场景完全是非常规的，Void的设计初衷就是表示“不可能存在的值”，用unsafe手段构造它本身就违背了类型系统的设计。

3. 编译器优化层面的差异 #

标准库的absurd定义是利用空case实现的：

absurd :: Void -> a
absurd v = case v of {}

编译器能直接识别出这是“完全不可达的分支”，会做很多优化——比如如果你的代码里有if impossibleCondition then absurd v else normalCode，编译器会直接删掉absurd分支，只保留正常逻辑。

而你给出的定义，因为有seq和递归的spin函数，编译器可能没办法像识别空case那样直接判断它是不可达代码，可能会生成一些冗余的递归代码（不过因为永远不会被调用，所以也不会有实际影响）。

总结一下：在正常的、符合类型安全的Haskell代码里，用不用seq没有任何区别；只有在违背类型系统的极端场景下，才会有运行时错误触发时机的差异，而这种场景本身就不应该出现。

内容的提问来源于stack exchange，提问作者Marius Catalin