在Java世界中，接口的命名约定已经非常成熟。例如，当您说某个类实现接口Comparable时，您可以说它的对象具有可比性。但是，类型类的命名约定并不是那么完善。例如，Int隐含Numeric隐式，因此您可以说“Int是Numeric类型”。但是有类型Ordering。我不明白为什么选择这个名字。 “Int是Ordering类型”没有任何意义。也许它应该被理解为“Int类型具有Ordering”。然后Scalaz中有Equal和Show。我完全不知道为什么选择这些名称（除了它们在Haskell中是这样的。）我试着查看类型的母语Haskell，以获得一个好的命名约定，但发现它确实没有。 Haskell的家伙似乎并不关心名字（这就是我从邮件列表讨论中收集的内容）。但是来自Java世界，我确实关心名字。我不太习惯于“类型说出一切”的范例。
问题是：如果你做的话，你会遵循哪些命名约定来命名类型类？
答案 0 :(得分：23)
实际上，Haskell中的事情基本上是直截了当的：类型类通常根据操作所代表的内容命名，而不是类型参数所代表的内容。
例如：
Read，Show：为其定义标准字符串序列化/反序列化函数的类型。Eq，Ord：分别定义了相等和排序关系的类型。Enum：定义“后继”操作的类型类，即可以枚举其值。Monoid，Functor，Monad：定义与类似命名的数学结构相关联的操作的类的类。有些例子并不是很好：例如，Num是一类类型，在这些类型上定义了一些模糊算术操作的临时集合，但没有理由{在任何传统意义上，{1}}实际上必须是数字。这也许可以手动作为“支持数字操作的类型”，假装“数字”实际上意味着该短语中的任何内容。
简而言之，Num可能是一个很难模仿的例子，如果一个类型只有一个函数（可能有多个变量），那么在该函数之后命名该类几乎总是安全的，如使用Numeric与show。
但实际上，主要的是根据类型类的函数来思考，而不是类型参数。想想动词，而不是名词。无论如何，名词都是愚蠢的惰性事物，因此在行动和操作方面进行思考可能会带来更好的程序设计。