Cómo organizar programas funcionales [cerrado]

Posible duplicado:
programación funcional versus OOP
¿Cómo escribir código manejable con programación funcional?

En OOP, su unidad básica de organización para el código es la clase. Una metodología utilizada con frecuencia en Java, C # y lenguajes similares es organizar su código alrededor de tener un archivo para cada clase con el nombre del archivo después del nombre de la clase.

Puede considerar cada una de estas clases como una unidad de organización para agrupar un solo concepto.

Estas clases están en espacios de nombres que a menudo siguen la estructura de directorios de los archivos en la solución / proyecto. Los espacios de nombres son otro nivel de organización.

¿Cómo se organizan típicamente los grandes proyectos en lenguajes funcionales?

¿Cómo se determina cómo dividir sus funciones en diferentes archivos?

¿Se utilizan otras unidades de agrupación junto a los archivos?

¿Cómo se organiza típicamente el código dentro de un solo archivo?

Sospecho que esto depende del idioma. En cuanto a la programación funcional, he incursionado principalmente en Haskell, así que voy a explicar cómo funciona allí.

El código de Haskell está organizado en "módulos" que son básicamente colecciones de funciones y tipos de datos. Cada módulo es un solo archivo. Un módulo es una especie de mezcla entre una clase Java y un paquete Java: el alcance exacto de lo que hace un módulo varía. Un módulo también tiene control sobre qué funciones y constructores de tipos exportar y cuáles ocultar; Esto es similar a privatey publicen Java.

En mis propios programas, me gusta que los módulos hagan una cosa, semánticamente; esto los hace como una clase de Java, excepto que podrían definir múltiples tipos de datos. Los módulos que uso de la biblioteca estándar, como Data.List, son más como paquetes: proporcionan un conjunto de funciones de utilidad similares. Esto también es muy similar a las clases estáticas de Java como java.util.Arrays.

Los módulos también son como paquetes Java, ya que se pueden anidar para mayor claridad (no creo que esto tenga ningún efecto en el código en sí). En general, para un solo proyecto, le doy un nombre (por ejemplo Project) y hago que todos mis módulos sean parte de esto (por ejemplo, Project.Parsey Project.Run). Si escribiera código que se pareciera más a una biblioteca que a una aplicación, lo organizaría en función de lo que estaba haciendo, como Data.Listo Control.Monad. Una diferencia importante con respecto a otros idiomas es que Haskell alienta la limitación de IO y la colocación de todo en un solo lugar. Una gran cantidad de módulos no hacen IO en absoluto, y para cualquier proyecto dado, me gusta tener tantos módulos como sea posible.

Como ejemplo, estoy trabajando en un lenguaje de programación simple al que llamo TPL (sin ninguna buena razón). Para esto, he creado dos módulos simples: TPL.Parseque define la representación interna del lenguaje y cómo analizarlo, y TPL.Runque ejecuta el intérprete y trata las variables y las IO. Para realmente compilar y ejecutar el código, generalmente hay un Mainmódulo que es lo que termina siendo el punto de entrada del programa.

Existe una gran libertad para organizar las funciones dentro de un archivo; Esto es justo lo que me gusta hacer. Defino mis tipos de datos hacia la parte superior, antes de que se usen en otro lugar. Justo después de definir los tipos de datos, implemento todo lo que necesito para hacerlos parte de sus clases de tipos apropiadas; esto es como implementar una interfaz. Luego sigo con lógica y varias funciones auxiliares, según corresponda. Finalmente, me gusta tener todas mis funciones IO en la parte inferior que terminan en main. Esto deja en claro exactamente qué está haciendo cualquier IO y dónde comienza el programa.

En resumen, las funciones están contenidas en módulos, cada uno de los cuales está formado por un solo archivo. Varios módulos pueden formar un programa o biblioteca; el primero generalmente incluye un Mainmódulo que es su punto de entrada. Dentro de un archivo, hay diferentes opciones de organización, pero prefiero agrupar los tipos de datos cerca de la parte superior, IO cerca de la parte inferior y la lógica en el medio.