Descomposición (modularidad) en los lenguajes funcionales

Tengo una idea: las funciones (en FP) podrían componerse de forma similar a los componentes en OOP. Para los componentes en OOP usamos interfaces. Para funciones podríamos usar delegados. El objetivo es lograr la descomposición, modularidad e intercambiabilidad. Podríamos emplear la inyección de dependencia para que sea más fácil.Descomposición (modularidad) en los lenguajes funcionales

Traté de encontrar algo sobre el tema. Sin suerte. ¿Probablemente porque no hay programas funcionales lo suficientemente grandes como para necesitar esto? Mientras buscaba aplicaciones de escala empresarial escritas en FP, encontré esta lista. Functional Programming in the Real World y this paper. Espero haberme perdido las aplicaciones más arriesgadas para FP, que serían lo suficientemente grandes como para merecer la descomposición.

Pregunta: ¿Podría mostrar la aplicación FP decente del mundo real (preferiblemente de código abierto), que usa la descomposición en módulos?

Bonus chatter: ¿Cuál es el patrón habitual? ¿Qué tipo de funciones generalmente se descomponen en módulos separados? ¿Alguna vez se burlaron de las implementaciones con fines de prueba?

Fuente

2010-09-22 Pavel Savara

No estoy familiarizado con un concepto de FP llamado "delegados". ¿A qué te refieres? – Chuck

Es el concepto C#/F #. Función fuertemente tipada - tipo de función. Similar a la interfaz con un solo método en Java. Ver http://msdn.microsoft.com/en-us/library/dd233206.aspx –

Acabo de encontrar un artículo relacionado interesante http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.143.2712&rep= rep1 & type = pdfq =% 20programming funcional% 20decomposition y ei = FY6aTOKvKcbxOf2cxaIP y USG = AFQjCNHZ39lndEyDRhmXzO-7O0s22ZQ1Jg y SIG2 = LtfPcDLYIPljaqR6uc-D5A & CAD = rja –

Hace algún tiempo estaba aprendiendo F # y preguntándome sobre los mismos temas, así que le pregunté acerca de quality open source projects to learn from.

La razón por la que no está viendo nada similar a la inyección de dependencia en la programación funcional es que es simplemente "natural", porque "se inyectan dependencias" solo por pasar o componer funciones. O como dice este artículo, "Functional dependency injection == currying", pero eso es solo un mecanismo.

Los marcos de burla no son necesarios. Si necesita burlarse de algo, simplemente pasa una función "stub".

Véase también this question about real-world Scala applications.

Fuente

2010-09-23 04:10:28

Buenos consejos, buena dirección. Déjame discutirlo un poco. Parece que propones pasar componentes-función en la llamada al método raíz. Con cientos de componentes que normalmente compongo en la aplicación OOP del mundo real, sería difícil. El artículo de Currying sugiere que puede dejar que el lenguaje elija componentes del contexto local (¿cierre?). Correcto, pero solo puedo imaginar contextos jerárquicos. Tal vez podría pasar una estructura que contenga componentes nombrados (contenedor efectivo) y resolver componentes-funciones por nombre. Pero eso es un localizador de enlace/servicio tardío. ¿Estoy reinventando algo? :-D –

@Pavel: sinceramente, aún no he desarrollado algo de esa escala en FP, pero mi experiencia hasta el momento con F # es que no siento la necesidad de un localizador/IoC de servicio, y tomo esto de alguien que es un drogadicto real de IoC en OOP :-) –

@Pavel: tal vez es porque las "dependencias" en FP son en realidad funciones simplemente por lo que se vuelven mucho más precisas, es decir, en lugar de pasar un IRepository completo, si necesita guardar una 'Entidad 'acaba de pasar una función' Entity -> unit', que es intercambiable trivialmente con cualquier cosa que cumpla con esa firma. –

O estamos hablando de objetivos cruzados (es posible: no estoy familiarizado con la terminología OOP) o te estás perdiendo mucho sobre programación funcional. Los módulos y la abstracción (es decir, la intercambiabilidad) se inventaron básicamente en el lenguaje funcional CLU. Los documentos fundamentales sobre los tipos abstractos son James Morris's Protection in programming languages y Types are not sets. Más tarde, la mayoría de las mejoras en los sistemas de módulos y la abstracción provienen del mundo de la programación funcional, a través de los lenguajes ML.

La aplicación asesina para la programación funcional a menudo se dice que es la manipulación simbólica. La mayoría de los compiladores de idiomas funcionales están escritos en el idioma en sí, de modo que puede buscar la fuente de su implementación de lenguaje funcional favorita. Pero casi cualquier programa no trivial (funcional o no) está escrito de alguna manera modular, tal vez me falta algo sobre lo que quiere decir con "descomposición". La modularidad será más visible y utilizará conceptos más avanzados en lenguajes fuertemente tipados con un sistema de módulo avanzado, como Standard ML y Objective Caml.

Fuente

2010-09-23 00:43:04 Gilles

Sí, todavía soy nuevo en FP. No, no me refiero a los módulos como vehículo de protección (de memoria). Prefiero decir que el módulo es algo que podrías reemplazar. En lenguajes fuertemente tipados, es la interfaz de un componente. Tendré que mirar el código de compiladores. Me lleva a preguntas sobre FP-inmutabilidad vs. AST y FP-no-side-effects vs. archivos de código, me pregunto si ese sería un buen ejemplo de FP code. De todos modos muchas gracias. –

@Pavel: tampoco me refería a la protección de la memoria. Estaba discutiendo módulos = componentes reemplazables y abstracción = reemplazabilidad (y sistema de módulos = la parte del lenguaje de programación que concierne a los módulos). La programación funcional, los sistemas de módulos y la inmutabilidad son conceptos ortogonales en gran medida, aunque funcionan bien juntos. – Gilles

Descomposición (modularidad) en los lenguajes funcionales

Respuesta

Cuestiones relacionadas