¿Cuál es la convención de nomenclatura para typeclasses en Scala?

haskell naming-conventions (1)

En el mundo de Java, las convenciones de nomenclatura para interfaces están bastante bien establecidas. Por ejemplo, cuando dice que cierta clase implementa la interfaz Comparable , puede decir que sus objetos son comparables. Sin embargo, las convenciones de nomenclatura para las clases de tipos no están tan bien establecidas. Por ejemplo, Int tiene un Numeric implícito disponible, por lo que puede decir " Int es un tipo Numeric ". Pero entonces hay orden de clases. No veo por qué se eligió este nombre. " Int es un tipo de Ordering " no tiene ningún sentido. Tal vez se supone que debe leerse como "El tipo Int tiene un Ordering ". Luego están Equal y Show en Scalaz. No tengo ni idea de por qué se eligieron estos nombres (aparte de lo que ocurre en Haskell). Intenté buscar en Haskell, la lengua materna de las clases de tipos, una buena convención de nombres, pero descubrí que realmente no existe. Los chicos de Haskell realmente no parecen preocuparse por los nombres (eso es lo que recogí de las discusiones de la lista de correo). Pero viniendo del mundo Java, me importan los nombres. No soy capaz de acostumbrarme al paradigma de "los tipos lo dicen todo".

La pregunta es: ¿Qué convenciones de nomenclatura sigues, si es que lo haces, para nombrar las clases de tipos?

En realidad, la mayoría de las cosas son sencillas en Haskell: las clases de tipos generalmente se nombran según lo que representan las operaciones , no lo que representa el parámetro de tipo .

Por ejemplo:

Read , Show : Clases de tipos para las cuales se definen las funciones estándar de serialización / deserialización de cadenas.
Eq , Ord : Clases de tipos en los que se definen las relaciones de igualdad y ordenación, respectivamente.
Enum : la clase de tipos que definen una operación "sucesora", es decir, cuyos valores se pueden enumerar.
Monoid , Functor , Monad : clases de tipos que definen las operaciones asociadas con las estructuras matemáticas con nombres similares.

Algunos ejemplos no son tan buenos: por ejemplo, Num es una clase de tipos en los que se define una colección ad-hoc de operaciones orientadas a aritmética vaga, pero no hay razón para que una instancia de Num deba ser realmente un número en cualquier sentido convencional. Esto quizás podría ser manual como "tipos que admiten operaciones numéricas", simulando que "numérico" en realidad significa algo en esa frase.

En resumen, Numeric es probablemente un mal ejemplo para imitar, y si una clase de tipo tiene solo una función (posiblemente con múltiples variantes), casi siempre es seguro nombrar a la clase después de esa función, como con show vs. Show .

Pero realmente, lo principal es pensar en términos de las funciones en la clase de tipo, no en el parámetro de tipo. Piensa verbos , no sustantivos . Los nombres son cosas tontas e inertes de todos modos, por lo que pensar en términos de acciones y operaciones puede llevar a un mejor diseño del programa.