¿Existe un lenguaje o estilo de modelado visual para el paradigma de programación funcional?

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

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 mientras deja varias opciones de implementación. Yendo más allá de Haskell a lenguajes con tipos dependientes, como en Agda y Coq (entre otros), los tipos son mucho más útiles como una especificación completa.

Donde los tipos no están basta con añadir especificaciones formales, que a menudo toman una forma funcional simple. (Por lo tanto, creo, las respuestas que el lenguaje de modelado de elección para Haskell es Haskell mismo o "matemáticas".) En tal forma, se da una definición funcional que está optimizada para la claridad y la simplicidad y no todo para la eficiencia. La definición podría incluso involucrar operaciones no configurables como la igualdad de funciones sobre dominios infinitos. Luego, paso a paso, transforma la especificación en la forma de un programa funcional computable eficientemente. Cada paso conserva la semántica (denotación), por lo que se garantiza que la forma final ("implementación") sea semánticamente equivalente a la forma original ("especificación"). Verá este proceso referido por 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 en su mayoría aplicaciones de "razonamiento ecuacional", aumentadas con algunas aplicaciones de inducción matemática (y co-inducción). Ser capaz de realizar un razonamiento tan simple y útil fue una motivación primaria para los lenguajes de programación funcionales en primer lugar, y deben su validez a la naturaleza "denotativa" de la "programación genuinamente funcional". (Los términos "denotativo" y "genuinamente funcional" son del documento seminal de Peter LandinLos Próximos 700 Lenguajes de programación.) Por lo tanto, el grito de guerra para la programación funcional pura solía ser " bueno para razonamiento ecuacional", aunque no escucho 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 denotativos/no-IO son buenos para el razonamiento ecuacional correcto, los tipos IO/no-denotativos están diseñados para ser malos para el razonamiento equacional 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 "semantic type class morphisms" (TCMs). La idea es dar 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 toda la funcionalidad del tipo a través de instancias de clase de tipo. Por ejemplo, digo que el significado de un tipo Image es como una función del espacio 2D. El principio TCM entonces me dice el significado de la Monoid, Functor, Applicative, Monad, Contrafunctor, and Comonad instances, as corresponding to those instances for función. Eso es un lote de funcionalidad útil en imágenes con especificaciones muy sucintas y convincentes! (La especificación es la función semántica más una lista de clases de tipo estándar para las cuales el principio semántico TCM debe contener.) Y sin embargo, tengo una tremenda libertad de cómo representar imágenes, y el principio semántico de la MTC elimina las fugas de abstracción. Si tienes curiosidad por ver algunos ejemplos de este principio en acción, echa un vistazo al documento Denotacional diseño con morfismos de clase tipo.

Sí, Haskell.

Tengo 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.

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

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

En Haskell, modelas por tipos.

Simplemente comience escribiendo sus firmas de función, clase y datos sin ninguna implementación e intente que los tipos encajen. El siguiente paso es QuickCheck.

Por ejemplo, para modelar una ordenación:

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 ...

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

También puede considerarse una herramienta de diseño, ya que admite la documentación de los programas, así como la construcción de ellos; creo que también puede pasar por la reescritura de los términos si lo desea para que pueda verlos desplegarse.

Desafortunadamente, Sin embargo, creo que ya no se desarrolla activamente.

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

Creo que apostaría por metodologías sistémicas como SADT/IDEF0.

• https://en.wikipedia.org/wiki/Function_model
• https://en.wikipedia.org/wiki/Structured_Analysis_and_Design_Technique

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

Puede un modelo de red de proceso de flujo de datos como se describe en Procesamiento de señales en tiempo real: Flujo de datos, Programación Visual y Funcional por 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:

¿Cuál sería el punto de modelar Haskell con matemáticas? Pensé que el punto de Haskell era que se relacionaba tan estrechamente con las matemáticas que los matemáticos podían recogerlo y correr con él. ¿Por qué traducirías un idioma a sí mismo?

Al trabajar con otro lenguaje de programación funcional (f#) utilicé diagramas en una pizarra que describían los bloques grandes y luego modelé el sistema de una manera OO usando UML, usando clases. Hubo una pequeña pérdida de partido en el edificio bloques en f# (divide las clases en estructuras de datos y funciones que actúan sobre ellas). Pero para la comprensión desde una perspectiva empresarial funcionó un placer. Añadiría mente que el problema era negocio / Web orientado y no sé cómo bien la técnica funcionaría para algo un pedacito 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 esté trabajando.

Uso el lenguaje USL - Universal Systems. Estoy aprendiendo Erlang y creo que encaja perfectamente.

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