Convenciones de nomenclatura del módulo Haskell

¿Cómo debo nombrar mis módulos Haskell para un programa, no una biblioteca, y organizarlos en una jerarquía?Convenciones de nomenclatura del módulo Haskell

Estoy haciendo un rastreador de rayos llamado Luminosity. Primero tuve estos módulos:

Vector Colour Intersect Trace Render Parse Export

Cada módulo estaba bien por sí mismo, pero me parecía que faltaba esta organización.

Primero, puse cada módulo en Luminosity, entonces por ejemplo Vector ahora era Luminosity.Vector (¿asumo que esto es estándar para un programa haskell?).

Luego pensé: Vector y Color son independientes y podrían reutilizarse, por lo que deberían separarse. Pero son demasiado pequeños para convertirse en bibliotecas.

¿Dónde deberían ir? Ya existe (en hackage) un Data.Vector y Data.Colour, entonces ¿debería ponerlos allí? ¿O eso causará confusión (incluso si los importo agrupados con mis otras importaciones locales)? Si no está allí, ¿debería ser Luminosity.Data.Vector o Data.Luminosity.Vector? Estoy bastante seguro de haber visto ambos usados, aunque tal vez simplemente vi un proyecto usando una estructura no convencional.

También tengo un exportador de imágenes TGA simple (Export) que puede ser independiente de Luminosity. Parece que la ubicación correcta sería Codec.Image.TGA, pero una vez más, ¿debería estar Luminosity en alguna parte y, de ser así, dónde?

Sería bueno si Structure of a Haskell project o algún otro wiki lo explicara.

Fuente

2012-07-21 mk12

Si desea hacer una pieza de código reutilizable, empaquételo en una biblioteca. El tamaño no importa. –

Vis módulos reutilizables para primitivas geométricas: con tipos algebraicos, vectores y colores son tan fáciles de definir que para un uso serio, un Haskeller querría definir el suyo propio en lugar de depender de otra biblioteca. Entonces tienen el control de sus representaciones y no tienen que preocuparse por los problemas de dependencia (cambios de API, fallas del autor, etc.) –

En primer lugar me puso cada módulo, bajo Luminosity

Creo que este fue un buen movimiento. Aclara a cualquiera que esté leyendo el código que estos módulos se hicieron específicamente para el proyecto Luminosity.

Si escribe un módulo con la intención de simular o mejorar una biblioteca existente, o de llenar un espacio donde cree que falta una biblioteca genérica en particular, en ese caso raro, suelte el prefijo y nómbrelo genéricamente. Para ver un ejemplo de esto, vea cómo el paquete pipes exporta Control.Monad.Trans.Free, porque el autor, por alguna razón, no estaba satisfecho con las implementaciones existentes de Mónadas gratuitas.

Luego pensé, Vector y Color son bastante independientes y podrían reutilizarse, por lo que deberían separarse. Pero son muy pequeños para separarse en una biblioteca (125 y 42 líneas, respectivamente). ¿A dónde deberían ir?

Si usted no hace una biblioteca independiente, entonces probablemente dejarlos en Luminosity.Vector y Luminosity.Colour. Si crea bibliotecas separadas, intente enviar correos electrónicos a la audiencia de destino de esas bibliotecas y vea cómo otras personas piensan que estas bibliotecas deben ser nombradas y categorizadas. Que se dividan o no en bibliotecas separadas depende totalmente de usted y de cuánto beneficio cree que estas bibliotecas separadas pueden ofrecer a otras personas.

Fuente

2012-07-22 03:02:19

Acepté su respuesta porque creo que fue la que más me ayudó y fue específica para mí, pero combiné los consejos de Norman y Stephen (comentario sobre la pregunta). Mantendré todo bajo 'Luminosidad.'como dijiste. No me molestaré en sacar bibliotecas de mis pequeños módulos o dejar caer el prefijo, ya que, como dijo Stephen, cada programa probablemente quiera sus propios vectores y colores de todos modos. Y mantendré todo plano en lugar de introducir una jerarquía debajo de "Luminosidad" por las razones dadas por Norman. – mk12

A menos que su programa sea realmente grande, no organice los módulos en una jerarquía. ¿Por qué no? Porque aunque las computadoras son buenas en jerarquía, las personas no lo son. La gente es buena en nombres significativos. Si elige buenos nombres, puede manejar fácilmente 150 módulos en un espacio de nombre plano.

Me sentí como si a [a flat name space] le faltara organización.

La organización jerárquica no es un fin en sí misma. Para justificar la división de módulos en una jerarquía, necesita un razón. Las buenas razones tienden a tener que ver con la ocultación o reutilización de la información. Cuando ingresas ocultando información, estás a medio camino del diseño de la biblioteca, y cuando hablas de reutilización, estás construyendo una biblioteca de manera efectiva. Convertir un gran programa en "programa más más biblioteca" es una buena estrategia para el software evolución, pero parece que recién está comenzando, y su programa aún no es lo suficientemente grande como para evolucionar de esa manera.

Estos problemas son en gran parte independientes del lenguaje de programación que está utilizando. Recomiendo leer parte del trabajo de David Parnas sobre líneas de productos y familias de programas, y también el documento no evaluado de Matthias Blume Hierarchical Modularity. Estos trabajos le darán algunas ideas más concretas sobre cuándo la jerarquía comienza a servir a un propósito.

Fuente

2012-07-21 20:35:58

¡Esta es una perspectiva interesante! Normalmente tengo al menos * alguna * forma de organización jerárquica en mis programas. ¿Cuál es su umbral de orden de magnitud para "realmente grande"? –

Entiendo su argumento, pero estoy en desacuerdo con la idea de que esto es independiente del lenguaje de programación. Al menos para evitar el nombramiento de colisiones, se debe introducir un nivel ('Luminosidad. *'). Sin embargo, no estoy seguro si se cuenta eso como una jerarquía. Realmente no estaba preguntando sobre los pros y contras de la jerarquía, estoy preguntando específicamente sobre las convenciones de Haskell. Tal vez esto sea bikeshedding, pero la jerarquía 'base' de Haskell (así como las de los paquetes en Hackage) parece muy diferente y menos simple que las convenciones de, digamos, Java o Python. – mk12

En cuanto a la discusión plana frente a la jerarquía, mi razonamiento detrás de hacer una jerarquía para mi programa de 8 módulos fue este: aproximadamente la mitad de los módulos no tenían nada que ver con el trazado de rayos. Puedo organizarlos apropiadamente en mi buscador de archivos localmente, pero en GitHub están todos alfabetizados. Pensé que facilitaría que las personas lo asimilaran agrupando los módulos relacionados. Lo cual parece ser exactamente lo contrario de lo que estás discutiendo. – mk12

Convenciones de nomenclatura del módulo Haskell

Respuesta

Cuestiones relacionadas