Haskell中Tab与空格使用规则及守卫语法缩进报错问题

核心规则：不存在必须4空格缩进的强制要求 #

Haskell的缩进基于词法层面的越位规则（Off-side rule），从来没有规定固定缩进宽度，判断逻辑只有两条：

• 当你开启一个新的代码块（包括守卫块、where/let绑定、do块、case分支等），块内所有代码的起始列位置，必须严格大于父级定义所在的起始列
• 同一个代码块内的所有同级元素，起始列必须完全对齐

你遇到的报错的具体原因 #

1. 缩进不满足越位规则，或同级元素未对齐 #

你写的1空格缩进报错、maximum'函数报错，本质都是违反了上面的规则，和缩进宽度是1还是4没有关系。比如你贴的报错的maximum'代码：

maximum' [] = error "maximum of empty list"  
maximum' [x] = x  
maximum' (x:xs)   
 | x > maxTail = x  
 | otherwise = maxTail  
 where maxTail = maximum' xs 

这段代码的问题有两个：

• 第三行maximum' (x:xs)末尾带有看不见的尾随空格，导致解析器判定该行的有效代码结束位置远晚于你视觉上看到的位置，换行后第2列位置的|没有满足“比父级定义块更靠右”的要求
• 守卫和where绑定属于函数定义下的同级块内容，这里where的起始列和|的起始列没有严格对齐，解析器会直接判定语法错误。

实际上只要对齐正确，1个空格缩进的守卫完全可以正常编译运行，比如下面的代码是合法的：

-- 守卫前仅1个空格，可正常编译
replicate' :: (Num i, Ord i) => i -> a -> [a]
replicate' n x
 | n <= 0    = []
 | otherwise = x:replicate' (n-1) x

2. Tab和空格混用导致的列计算偏差 #

你听到的“始终使用空格”的规则，从来不是“空格优先级高于Tab”，而是Haskell标准规定编译器解析时，Tab字符固定按8个空格宽度计算列位置。如果你的编辑器把Tab显示为4个空格宽度，你视觉上看着代码是对齐的，编译器计算出的列位置会差一倍，自然会报各种玄学缩进错误。全用空格就能彻底避免这个显示和解析的宽度差问题。

3. GHCI 与编辑器配置的额外影响 #

• GHCI默认是单行解析模式，没有自动识别多行块的完整逻辑，如果你逐行输入带守卫的函数，只要缩进稍有不足，GHCI就会判定上一行输入已经结束，直接抛出语法错误。在GHCI中写多行代码建议先输入:{开启多行块，写完后输入:}结束解析，能规避90%的GHCI缩进误报。
• 你用的Sublime默认没有针对Haskell开启自动修剪尾随空格、Tab自动转空格的配置，很容易出现视觉上对齐、实际藏了尾随空格/混用Tab空格的问题，触发解析错误。

实用配置建议 #

给Sublime添加针对Haskell文件的专属配置即可解决大部分编辑器导致的缩进问题：

• 开启translate_tabs_to_spaces，输入Tab时自动替换为对应数量的空格，彻底规避Tab宽度不一致问题
• 开启trim_trailing_white_space_on_save，保存文件时自动删除行尾看不见的多余空格，避免尾随空格干扰列位置计算

日常写代码不需要死记“必须缩进4空格”的要求，只要记住“新块缩进比父级靠右、同级元素严格对齐”两个原则，就不会写出缩进错误的代码。

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