为带单位温度类型实现Show：Proxy方案是否优于简易实现？

一、你的简易方案的实际可用性缺陷 #

你的方案（给F/C单独实现Show，再在Temp F/Temp C的Show里用undefined获取单位标识）不止是不够优雅，确实存在实际可用性缺陷：

• 语义混淆与维护风险：undefined在Haskell中代表未定义的异常值，用它来获取类型对应的字符串属于“取巧式hack”——本质是利用幻影类型无值的特性，但完全违背了undefined的语义。后续维护者看到这段代码会产生困惑，若不小心修改F/C的Show实例使其依赖值（哪怕是误操作），会直接触发运行时异常。
• 违反DRY原则：如果后续新增温度单位（比如开尔文K），你需要重复编写Temp K的Show实例，代码重复度随单位数量增加而上升。而书中用Proxy的方案可以实现一个通用Show实例，仅需为每个单位类型提供对应的单位字符串即可。
• 类型安全性打折扣：这种写法没有遵循Haskell类型系统的规范用法。幻影类型的类型信息传递，规范方式是通过Proxy或TypeApplications，而非依赖无意义的undefined值，后者弱化了类型系统的严谨性。

举个反例，若你误给F添加带值的构造器：

data F = F String
instance Show F where show (F s) = s

此时你的Show (Temp F)实例中show undefined会直接抛出运行时错误，而书中的Proxy方案完全不受影响。

二、幻影类型方案 vs 单独定义TempF/TempC的优势 #

直接定义TempF Double、TempC Double这类单独类型看似直观，但书中的幻影类型（Temp a）方案有以下核心优势：

1. 极致的代码复用 #

所有温度相关逻辑都能复用：

• 通用取值函数：getValue :: Temp a -> Double，无需编写getTempF :: TempF -> Double、getTempC :: TempC -> Double等重复函数。
• 通用转换逻辑：通过类型类定义跨单位转换，比如：

  class TemperatureUnit a where
    toKelvin :: Temp a -> Double
    fromKelvin :: Double -> Temp a
  
  instance TemperatureUnit F where
    toKelvin (Temp f) = (f - 32) * 5/9 + 273.15
    fromKelvin k = Temp $ (k - 273.15) * 9/5 + 32
  
  instance TemperatureUnit C where
    toKelvin (Temp c) = c + 273.15
    fromKelvin k = Temp $ k - 273.15
  
  convert :: (TemperatureUnit a, TemperatureUnit b) => Temp a -> Temp b
  convert = fromKelvin . toKelvin
  

  这个convert函数可处理任意两个支持的温度单位转换，无需为每对单位编写单独的转换函数（如convertCF、convertFC）。

2. 更强的类型安全约束 #

幻影类型可通过类型类约束限制操作合法性。比如你可以定义CanAdd a b c类型类，仅允许特定单位的温度相加得到对应单位的结果；而单独类型方案需要为合法组合编写单独的add函数，无法通过类型系统统一约束。

3. 极低的扩展成本 #

新增温度单位（比如K）时，仅需：

• 定义幻影类型data K
• 实现TemperatureUnit K实例
• 实现单位字符串相关实例（如Show或专门的UnitName类型类）
  无需新增数据类型、取值函数、转换函数等，扩展成本几乎为零。而单独类型方案需要新增TempK及对应的所有操作函数，代码冗余度会随单位数量增加而爆炸。

4. 统一的接口与抽象 #

所有温度值都属于Temp a类型，可作为统一参数传递给通用函数。比如你可以写printTemperature :: (Show (Temp a)) => Temp a -> IO ()，它能打印任何单位的温度，无需编写printTempF、printTempC等多个函数。

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