所有 Haskell 函子都是内函子吗？
我有点困惑，需要有人来纠正我。让我们概述一下我目前的理解：
其中 E 是一个 endofunctor，而 A 是某个类别：
E : A -> A.
因为 Haskell 中的所有类型和态射都在 Hask 中范畴，Haskell 中的任何函子不也是一个endofunctor吗？ F：Hask ->哈斯克。
我有一种强烈的感觉，我错了，并且在某种程度上过于简单化了，我希望有人告诉我我是一个多么白痴的人。谢谢。
I'm a bit confused, and need someone to set me straight. Lets outline my current understanding:
Where E is an endofunctor, and A is some category:
E : A -> A.
Since all types and morphisms in Haskell are in the Hask category, is not any functor in Haskell also an endofunctor? F : Hask -> Hask.
I have a good feeling that I'm wrong, and oversimplifying this somehow, and I'd like someone to tell me what an idiot I am. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可能想澄清您是在询问“Haskell 中的函子”还是函子。在 Haskell 中使用范畴论术语时，并不总是清楚假设的范畴是什么。
但是，是的，默认假设是 Hask，它被视为具有态射函数的 Haskell 类型类别。在这种情况下，Hask 上的 endofunctor F 会将任何类型 A 映射到类型 F(A)，并将两种类型 A 和 B 之间的任何函数 f 映射到函数 F( f) 介于某些类型 F(A) 和 F(B) 之间。
如果我们将自己限制为仅将任何类型
a映射到类型(fa)的 endofunctor，其中f是类型构造函数 <代码>* -> *，那么我们可以将函数的关联映射描述为类型为(a -> b) ->; 的高阶函数。 (fa -> fb)，这当然是称为Functor的类型类。然而，我们可以很容易地想象 Hask 上行为良好的 endofunctors 不能（直接）编写为
Functor的实例，例如映射类型的函子>a到a t。虽然从 Hask 到其他类别的函子显然没有多大意义，但考虑从 Hask 到 Hask 的（逆变）函子是合理的强>op。除此之外，
Functor的实例必须从整个类别 Hask 映射到它的某个子集，从而也形成一个类别。但讨论 Hask 子集之间的函子也是合理的。例如，考虑一个将类型Maybe a发送到[a]的函子。您可能希望仔细阅读
category-extras包，它提供了一些嵌入在 Hask 中的受类别理论启发的结构，而不是假设它的全部。You may want to clarify whether you're asking about "functors in Haskell", or
Functors. It's not always clear what category is being assumed when Category Theory terms are used in Haskell.But yes, the default assumption is Hask, which is taken to be the category of Haskell types with functions as morphisms. In that case, an endofunctor F on Hask would map any type A to a type F(A) and any function f between two types A and B to a function F(f) between some types F(A) and F(B).
If we then limit ourselves to only those endofunctors which map any type
ato a type(f a)wherefis a type constructor with kind* -> *, then we can describe the associated map for functions as a higher-order function with type(a -> b) -> (f a -> f b), which is of course the type class calledFunctor.However, one can easily imagine well-behaved endofunctors on Hask which can't be written (directly) as an instance of
Functor, such as a functor mapping a typeatoEither a t. And while there's obviously not much sense in a functor from Hask to some other category entirely, it's reasonable to consider a (contravariant) functor from Hask to Haskop.Beyond that, instances of
Functornecessarily map from the entire category Hask onto some subset of it that, thus, also forms a category. But it's also reasonable to talk about functors between subsets of Hask. For instance, consider a functor that sends typesMaybe ato[a].You may wish to peruse the
category-extraspackage, which provides some Category Theory-inspired structures embedded within Hask instead of assuming the entirety of it.即使最终您操作
Hask，也可以在Hask上构建许多其他类别，这对于当前的问题可能有意义：Hask^op，即Hask，所有箭头反转Hask * Hask，其上的函子为bifunctorsa的态射，态射是交换三角形 函子获取 Mac Lane 的 的副本em>工作数学家的类别有定义，并尝试自己找到他们在 Haskell 中解决的问题。尤其是伴随函子（它们是正确类别中的初始/终止对象）及其与单子的关系。
您会发现，即使有一个大类别（
Hask，或者可能是“使用右箭头/产品/...从Hask提升对象”，它封装了Haskell 的语言选择（例如非严格性和惰性），适当的派生类别是富有表现力的。Even if ultimately, you manipulate
Hask, there are a lot of other categories that can be built onHask, which can be meaningful for the problem at hand:Hask^op, which isHaskwith all arrows reversedHask * Hask, functors on it are bifunctorsa, morphisms are commutative trianglesgrab a copy of Mac Lane's Categories for the Working Mathematician to have definitions, and try to find by yourself the problem they solve in Haskell. Especially choke on adjoint functors (which are initial/terminal objects in the right category) and their relationship with monads.
You'll see that even if there is one big category (
Hask, or perhaps "lifted objects fromHaskwith the right arrows/products/...", which encapsulates the language choices of Haskell such as non-strictness and lazyness), proper derived categories are expressive.在论文“Monads need not be endofunctors”中可以找到专门关于 monad 的可能相关（或至少有趣）的讨论：
http://www.cs.nott.ac.uk/~txa/publ/Relative_Monads.pdf
A possibly relevant (or at least interesting) discussion specifically regarding monads is found in the paper "Monads need not be endofunctors":
http://www.cs.nott.ac.uk/~txa/publ/Relative_Monads.pdf