多参数类型类与数据类型的选型对比及实践疑问

一、何时选用多参数类型类（MPTC） #

多参数类型类的核心是绑定类型之间的全局、唯一关系，适合以下场景：

• 存在唯一的标准实现：当某组类型之间的关系是数学上的标准抽象，或者业务逻辑中全局只有一种合理的实现方式时，用MPTC可以避免显式传递实现，减少样板代码。比如整数对数值类型的加法作用，全局只有一种符合直觉的实现，此时用MPTC能让代码更简洁。
• 依赖自动推导与约束传播：如果多个函数都需要依赖同一种类型关系，MPTC的约束可以通过编译器自动推导，不需要在每个函数中显式传递实现实例。比如大量函数都需要用到Monoid m => Action m a的作用逻辑时，类型类约束比传递数据实例更省心。
• 需要与其他类型类组合交互：结合函数依赖（FunctionalDependencies）或类型族（TypeFamilies），MPTC可以表达复杂的类型依赖关系，比如全局的类型转换class Convert a b where convert :: a -> b，这种场景下用MPTC能统一约束转换逻辑。

二、何时选用数据类型 #

数据类型的核心是承载具体的、可复用的实现逻辑，适合以下场景：

• 同一类型对存在多种合法实现：当同一组类型之间可以有多种不同的操作逻辑时，数据类型允许你定义多个不同的实例值。比如透镜（Lens）：同一个Person类型和String类型，可以对应“取名字”“取昵称”等多个透镜；再比如整数对列表的作用，可以有“左折叠累加”“元素级乘法”等多种方式，此时数据类型能灵活支持这些不同实现，而MPTC只能绑定全局唯一实例。
• 需要显式传递、组合操作逻辑：数据类型可以作为参数传递给高阶函数，还能进行组合（比如透镜的(.)组合）。而MPTC的操作是全局固定的，无法在函数内部动态切换不同的实现方式。
• 避免全局实例冲突：MPTC的全局实例可能导致孤儿实例、意外的实例覆盖等问题，而数据类型的实现是显式的，完全由开发者控制，不会出现全局作用域的冲突。
• 提升可读性与可调试性：数据类型是显式的值，你可以直接查看、打印或者跟踪它的传递路径；而MPTC的实例是全局隐式的，调试时需要查找全局的实例定义，不够直观。

三、monoid-extras库的Action实现是否存在问题？ #

monoid-extras中的Action定义大致如下：

class Monoid m => Action m a where
  act :: m -> a -> a

它的合理性取决于你的使用场景：

• 无问题的场景：如果你的业务中，某个Monoid类型m对类型a只有唯一的标准作用方式，那么这个实现非常方便——不需要显式传递作用实例，编译器自动推导即可，能减少代码量。
• 存在局限的场景：如果同一组m和a需要支持多种作用方式，MPTC的设计就会带来麻烦。比如整数作为Sum monoid对列表的“累加元素”作用，和作为Product monoid的“累乘元素”作用，此时你必须用newtype包装类型来区分实例，会增加不必要的样板代码。
• 理念层面的争议：从数学定义来看，“半群/幺半群作用”是一个具体的结构，而非类型之间的固有绑定——同一个幺半群可以以多种方式作用在同一个集合上。MPTC把作用方式绑定到类型对的全局关系上，这在部分场景下不符合数学直觉，而数据类型更贴合“作用是一个独立结构”的定义。

总的来说，monoid-extras的Action并非“有问题”，而是有其适用边界，在简单的全局唯一作用场景下很实用，但在需要多实现的复杂场景中，数据类型的方案会更灵活。

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