programming languages - programacion - ¿Hay un lenguaje o estilo de modelado visual para el paradigma de programación funcional?

programacion funcional ventajas y desventajas (11)

UML es un estándar destinado al modelado de software que se escribirá en lenguajes OO, y va de la mano con Java. Aún así, ¿podría posiblemente usarse para modelar software que debe escribirse en el paradigma de programación funcional? ¿Qué diagramas serían útiles dado los elementos visuales incrustados?

¿Hay un lenguaje de modelado dirigido a la programación funcional, más específicamente Haskell? ¿Qué herramientas para armar diagramas recomendarías?

Editado por OP 02 de septiembre de 2009:

Lo que estoy buscando es la representación más visual y más liviana de lo que sucede en el código. Diagramas fáciles de seguir, modelos visuales no necesariamente dirigidos a otros programadores. Desarrollaré un juego en Haskell muy pronto, pero como este proyecto es para el trabajo de conclusión de mi graduación, necesito introducir algún tipo de formalización de la solución propuesta. Me preguntaba si existe un equivalente al estándar UML + Java, pero para Haskell. ¿Debería limitarme a los guiones gráficos, a las descripciones escritas, a los diagramas no formales (algunas imágenes de flujogramas poco profundos), a las descripciones de casos de uso no formalizadas?

Editado por jcolebrand el 21 de junio de 2012:

Tenga en cuenta que originalmente quería una metáfora visual, y ahora que hemos tenido tres años, estamos buscando más / mejores herramientas. Ninguna de las respuestas originales realmente abordó el concepto de "herramienta visual de diseño de metáforas", así que ... eso es lo que la nueva generosidad busca proporcionar.

¿Cuál sería el objetivo de modelar Haskell con Maths? Pensé que el objetivo de Haskell era que se relacionara tan estrechamente con las Matemáticas que los matemáticos pudieran retomarlo y correr con él. ¿Por qué traducirías un idioma a sí mismo?

Cuando trabajaba con otro lenguaje de programación funcional (f #), usé diagramas en una pizarra blanca que describían los bloques grandes y luego modelé el sistema de manera OO usando UML, usando clases. Hubo una pequeña coincidencia en los bloques de construcción en f # (dividir las clases en estructuras de datos y funciones que actuaron sobre ellos). Pero para entenderlo desde una perspectiva comercial, funcionó bien. Agregaría que el problema está orientado a los negocios / web y no sé qué tan bien funcionaría la técnica para algo un poco más financiero. Creo que probablemente capturaría las funciones como objetos sin estado y deberían encajar muy bien.

Todo depende del dominio en el que trabajes.

Aunque no es una recomendación para usar (ya que parece que no está disponible para su descarga), el sistema HOPS visualiza gráficas de términos, que a menudo son una representación conveniente de programas funcionales.

También se puede considerar una herramienta de diseño, ya que permite documentar los programas y construirlos; Creo que también puede pasar por la reescritura de los términos si lo desea para que pueda verlos unfold .

Desafortunadamente, creo que ya no se desarrolla activamente.

Creo que el lenguaje de modelado de Haskell se llama " math ". A menudo se enseña en las escuelas.

En Haskell, modelas por tipos.

Simplemente comience por escribir sus firmas de funciones, clases y datos sin ninguna implementación e intente adaptar los tipos. El siguiente paso es QuickCheck.

Por ejemplo, para modelar un tipo:

class Ord a where compare :: a -> a -> Ordering sort :: Ord a => [a] -> [a] sort = undefined

luego prueba

prop_preservesLength l = (length l) == (length $ sort l) ...

y finalmente la implementación ...

He visto algunas entrevistas en video y he leído algunas entrevistas con gente como erik meijer y simon peyton-jones. Parece que cuando se trata de modelar y comprender el dominio de un problema, usan firmas de tipo, especialmente las firmas de función.

Los diagramas de secuencia (UML) podrían estar relacionados con la composición de funciones. Un diagrama de clase estático (UML) podría estar relacionado con las firmas de tipo.

Me doy cuenta de que llego tarde a la fiesta, pero aún daré mi respuesta en caso de que alguien la encuentre útil.

Creo que iría por metodologías sistémicas de la talla de SADT / IDEF0.

Dichos diagramas se pueden hacer con el programa Dia que está disponible en Linux, Windows y MacOS.

Puede utilizar un modelo de red de proceso de flujo de datos como se describe en Procesamiento de señal en tiempo real: flujo de datos, programación visual y funcional de Hideki John Reekie

Por ejemplo, para código como (Haskell):

fact n | n == 0 = 1 | otherwise = n * fact (n - 1)

La representación visual sería:

Sí, Haskell.

Me da la impresión de que los programadores que usan lenguajes funcionales no sienten la necesidad de simplificar su lenguaje de elección cuando piensan en su diseño, que es una forma (bastante simplista) de ver lo que UML hace por usted.

Sí, hay lenguajes / técnicas de modelado / especificación ampliamente utilizados para Haskell. No son visuales.

En Haskell, los tipos dan una especificación parcial . A veces, esta especificación determina completamente el significado / resultado al dejar varias opciones de implementación. Yendo más allá de Haskell a los idiomas con tipos dependientes, como en Agda & Coq (entre otros), los tipos son mucho más a menudo útiles como una especificación completa .

Cuando los tipos no son suficientes, agregue las especificaciones formales, que a menudo toman una forma funcional simple. (Por lo tanto, creo que la respuesta es que el lenguaje de modelado elegido por Haskell es Haskell o "matemática"). De esta forma, se obtiene una definición funcional optimizada para la claridad y la simplicidad, y no para la eficiencia. La definición podría incluso incluir operaciones no procesables, como la igualdad de funciones en dominios infinitos. Luego, paso a paso, transforma la especificación en la forma de un programa funcional eficientemente computable. Cada paso preserva la semántica (denotación), por lo que se garantiza que la forma final ("implementación") será semánticamente equivalente a la forma original ("especificación"). Verá este proceso al que se hace referencia con varios nombres, incluyendo "transformación de programa", "derivación de programa" y "cálculo de programa".

Los pasos en una derivación típica son principalmente aplicaciones de "razonamiento ecuacional", aumentadas con algunas aplicaciones de inducción matemática (y co-inducción). Poder realizar un razonamiento tan simple y útil fue, en primer lugar, una motivación primaria para los lenguajes de programación funcionales, y deben su validez a la naturaleza "denotativa" de la "programación genuinamente funcional". (Los términos "denotativo" y "genuinamente funcional" provienen del novedoso libro de Peter Landin, Los próximos 700 lenguajes de programación .) Por lo tanto, el grito de la programación funcional pura solía ser "bueno para el razonamiento ecuacional", aunque no oigo esa descripción casi tan a menudo en estos días. En Haskell, denotativo corresponde a tipos distintos de IO y tipos que dependen de IO (como STM ). Mientras que los tipos denotativo / no IO son buenos para el razonamiento ecuacional correcto, los tipos IO / no denotativo están diseñados para ser malos para el razonamiento ecuacional incorrecto.

Una versión específica de derivación-de-especificación que uso tan a menudo como sea posible en mi trabajo de Haskell es lo que llamo "morfismos de clase de tipo semántico" (TCM). La idea es proporcionar una semántica / interpretación para un tipo de datos, y luego usar el principio TCM para determinar (a menudo de manera única) el significado de la mayoría o la totalidad de la funcionalidad del tipo a través de instancias de clase de tipo. Por ejemplo, digo que el significado de un tipo de Image es como una función del espacio 2D. El principio TCM me dice el significado de las instancias Comonad , Functor , Applicative , Monad , Contrafunctor y Comonad , que corresponden a esas instancias para funciones. ¡Es una gran cantidad de funcionalidad útil en imágenes con especificaciones muy sucintas y atractivas! (La especificación es la función semántica más una lista de clases de tipos estándar para las cuales debe mantenerse el principio semántico TCM.) Y sin embargo, tengo una tremenda libertad de cómo representar imágenes, y el principio semántico TCM elimina las fugas de abstracción. Si tiene curiosidad por ver algunos ejemplos de este principio en acción, consulte el diseño denotacional en papel con morfismos de clase de tipo .

Uso USL - Universal Systems Language. Estoy aprendiendo Erlang y creo que es un ajuste perfecto.

Lástima que la documentación es muy limitada y nadie la usa. Más información here .

Utilizamos demostradores de teoremas para hacer modelos formales (con verificación), como Isabelle o Coq. A veces utilizamos lenguajes específicos de dominio (por ejemplo, Cryptol) para hacer el diseño de alto nivel, antes de derivar la implementación de Haskell de "bajo nivel".

A menudo solo usamos Haskell como lenguaje de modelado y derivamos la implementación real mediante la reescritura.

Las propiedades QuickCheck también juegan un papel en el documento de diseño, junto con las descomposiciones de tipo y módulo.