为什么Functor要对map的定义作出约束？

1. 为什么asdf和map同类型却不合法 #

首先asdf的类型签名和标准map完全一致，类型检查器会直接放行，但它本质上是一个特殊化的实现：它主动丢弃了输入列表除首元素外的所有内容，只保留了首元素的映射结果。这种实现对调用方是不可预期的——调用方看到(a -> b) -> [a] -> [b]的签名，默认会认为输出列表长度和输入列表一致，asdf显然违背了这个预期。

2. Functor约束的作用 #

Functor的两条强制定律 #

所有实现Functor的类型都必须遵守两条规则，这两条规则刚好排除了asdf这类非法实现：

• 恒等律：fmap id = id
  对任意容器应用fmap id（用恒等函数映射容器内所有元素），得到的结果必须和原容器完全一致。
  我们用asdf验证：asdf id [1,2,3]得到的结果是[1]，和原列表[1,2,3]完全不等，直接违反恒等律，因此asdf不可能成为Functor的合法实现。
• 组合律：fmap (f . g) = fmap f . fmap g
  先把两个函数组合再映射，和先映射第一个函数再映射第二个函数的结果完全一致。

泛化签名的限制作用 #

你提到的“List给实现者过多信息”是问题的核心：
当你直接针对[]（列表）类型写(a -> b) -> [a] -> [b]签名的函数时，你可以直接访问列表的内部结构，自由选择丢弃元素、调整长度，没有任何限制。
但如果我们把函数签名泛化为Functor f => (a -> b) -> f a -> f b，就要求这个函数对所有符合Functor定律的容器都生效，你无法知道f的具体内部结构，也不能针对特定容器做特殊处理，只能用Functor提供的标准接口操作，自然就没法写出丢弃元素、修改容器结构的实现了。

3. 和参数性的关联 #

演讲里提到的参数性（Parametricity）核心逻辑就是：足够泛化的多态签名，可以大幅限制函数的可能实现范围，甚至可以通过签名直接推断函数的行为。Functor约束本质上是给这个泛化签名加上了“容器结构不变”的保证，从规则层面排除了asdf这类不符合预期的实现。

内容的提问来源于stack exchange，提问作者F. Zer