我希望从基础的角度来看Haskell中所谓的函数。
从类别上看，有些事物具有联想功能，具有身份功能，从理论上讲就足够了。
但是每个人都试图说服我，这不是定义函数的方式。一个函数被定义为（它们说）满足两个条件（域和codoman）的一组元素对。意味着一个功能仅仅是一个集合。无法在非集合上定义函数。
如果将这种方法应用于Haskell，我看到的是Hask类别只是Sets的子类别，在我看来，这很奇怪。
我宁愿将功能的概念扩展到适用于Haskell中的功能。
Here在此问题的评论中被切切触及，但不是很深。我想听到一个明确的声明，例如“但实际上它们都是集合”，或“不，我们与集合论无关”。
有什么想法吗？注意事项？
答案 0 :(得分：8)
这是一个非常复杂的主题。为了使其简单易管理，我们经常偷工减料，经常“撒谎”。
与所有编程语言一样， Haskell具有自己的语法和评估规则（操作语义）。但是，仅从操作角度考虑编程语言会非常有限且麻烦。当我们调用factorial函数时，我们并不关心它的实现方式，也不关心它提供结果所需的确切评估步骤数。
为克服这种<符号>名词化语义，提出了在某些“数学”模型中逐段解释语法的方法。许多不同的程序（句法表达式）可能映射到相同的解释（“语义”）。
据我所知，整个Haskell语言的代名词语义从未定义。但是，存在Haskell片段的模型。这些模型通常是类别。
以下是一些示例。
如果我们（非常！）将Haskell限制为一个终止的，简单类型的核，那么我们所需要的只是一个（双）笛卡尔封闭类别，以及集合的类别及其产品，副产品和指数就足够了。 / p>
但是，Haskell不会终止，并且具有一般递归，因此我们需要固定点。通常，这可以通过移至完全不完整订单的类别（通常是omega-CPO或DCPO之间的一个）来解决。
然后，我们需要类型级的不动点，因此我们需要考虑具有初始F代数的类别（至少对于行为良好的函子F而言）。这使事情变得更加复杂。
我们还没有添加多态性！这是特别棘手的，因为雷诺兹（Reynolds）证明了不能用集合天真地建模多态性（“主要的参考文献不是基于集合的多态性”）。因此，我们现在有了PER模型和Coherent模型（均为类别），作为为多态性提供语义的一些尝试。
然后我们需要类型类，GADT，更高的等级，更高的种类...
实际上，我们不需要这种级别的复杂性。编程时，我们通常处理有限的功能，因此我们对自己“撒谎”，并经常假装一切工作都像一个集合，或者足够接近。然后，如果确实需要，我们可以增加复杂性。