functional programming - programacion - Especificación para un lenguaje de programación funcional reactiva

programacion funcional ventajas y desventajas (2)

Estoy pensando en crear un marco reactivo funcional en algún momento. He leído mucho sobre él y he visto algunos ejemplos, pero quería tener una idea clara de lo que este marco TENDRÍA que hacer para ser considerado una extensión / dsl de FRP. No estoy realmente preocupado con problemas de implementación o específicos, etc., sino más bien con lo que se desea en una situación mundial perfecta.

¿Cuáles serían las operaciones y cualidades clave de un lenguaje de programación funcional ideal?

Me complace que comiences preguntando primero por una especificación en lugar de por una implementación. Hay muchas ideas flotando alrededor de lo que es FRP. Para mí, siempre han sido dos cosas: (a) denotativo y (b) temporalmente continuo. Muchas personas abandonan ambas propiedades e identifican FRP con varias nociones de implementación , todas las cuales están fuera del punto en mi perspectiva. Para reducir la confusión, me gustaría que el término "programación reactiva funcional" sea reemplazado por "programación denotativa y continua" más precisa y descriptiva (DCTP), como lo sugirió Jake McArthur en una conversación el año pasado .

Por "denotativo" me refiero a una semántica compositiva precisa, simple, independiente de la implementación, que especifica exactamente el significado de cada tipo y bloque. La naturaleza compositiva de la semántica luego determina el significado de todas las combinaciones de tipo correcto de los bloques de construcción. Para mí, denotativo es el corazón y la esencia de la programación funcional, y es lo que permite un razonamiento preciso y manejable y, por lo tanto, una base para la corrección, la derivación y la optimización. Peter Landin recomendó "denotativo" como un reemplazo sustancial al término más confuso "funcional" y una manera de distinguir la programación profunda / genuinamente funcional de las notaciones de apariencia meramente funcional. Vea este comentario para algunas citas de Landin y una referencia en papel.

Acerca del tiempo continuo, consulte la publicación ¿Por qué programar con tiempo continuo? y mi cita en la respuesta de AshleyF en esta página. Me sorprende una y otra vez escuchar la afirmación de que la idea del tiempo continuo es de alguna manera antinatural o imposible de implementar, teniendo en cuenta la naturaleza discreta de las computadoras. Esta línea de pensamiento me parece extraña, especialmente cuando proviene de Haskellers, por algunas razones:

Usando lenguajes funcionales perezosos , casualmente programamos con datos infinitos en máquinas finitas . Obtenemos una modularidad encantadora como resultado, como se ilustra en el artículo clásico de John Hughes Why Functional Programming Matters .
Hay muchos ejemplos de programación en espacio continuo, por ejemplo, gráficos vectoriales, pero también cosas como Pan .
Me gusta que mis programas reflejen mi opinión sobre el espacio problemático en lugar de la máquina que ejecuta los programas, y tiendo a esperar que otros programadores de idiomas de alto nivel compartan esa preferencia. ("Un lenguaje de programación es de bajo nivel cuando sus programas requieren atención a lo irrelevante". - Alan Perlis)

He estado creando bibliotecas para programar con tiempo continuo desde TBAG y ActiveVRML (el primer sistema DCTP / FRP) y luego Fran . Es fácil de implementar correctamente. Se describen algunos enfoques diferentes en el documento Implementaciones Funcionales de Animación Modelada Continua . Implementar el tiempo continuo de manera eficiente (¡y aún correctamente!) Es otra cuestión, especialmente evitar el volver a calcular los valores invariables. (Consulte la programación reactiva funcional Push-pull en papel).

Para comentarios relacionados, consulte mi respuesta a La diferencia entre la programación reactiva y reactiva funcional y a ¿Qué es la programación reactiva (funcional)? Actualización: para obtener más información sobre por qué el tiempo continuo importa, consulte estas notas . Actualización: Ver también, mi charla de 2015 La esencia y orígenes de FRP (y las conversaciones relacionadas vinculadas allí).

Buena suerte con su exploración, y por favor hágamelo saber si tiene alguna pregunta. Mi información de contacto está en mi página de inicio .

Supongo que probablemente haya visto la charla de Matthias Felleisen sobre I / O funcional y lea su artículo . Creo que es un enfoque muy pragmático y hermoso. Afortunadamente también ha tropezado con parte del excelente trabajo de Conal Elliott .

Mis requisitos personales serían que el sistema sea completamente puro. Es decir, todo el comportamiento se define por las funciones puras world->world y toda realización o visualización se define por world->visual funciones world->visual ; donde visual es una descripción estática de la salida del sistema.

Mi otra característica principal sería un depurador histórico. Debería ser relativamente trivial mantener una historia de world estados del world y ser capaz de reproducir desde cualquier punto del tiempo.

Un área de investigación extremadamente interesante (creo que un problema no resuelto) sería utilizar el tiempo continuo en lugar de iterar las funciones world->world en algunos tic- tac del reloj discretos. Una vez escribí algunas publicaciones en el blog sobre FRP y Conal Elliott me dejó el siguiente comentario que me hizo pensar:

Me gustan los enfoques denotativos / funcionales, para la compibilidad y la claridad semántica. Por las mismas razones, prefiero el tiempo y el espacio continuos en lugar de tiempo y espacio discretos. En todos estos casos, la formulación menos similar a una máquina separa muy bien el qué de la presentación basada en la máquina.

¡Resuelve eso y serás un héroe!