FRP-Event streams and Signals-¿qué se pierde al usar solo señales?

Se pierde algo críticamente importante para mí, a saber, la esencia de los comportamientos, que es (posiblemente continua) la variación sobre el tiempo continuo. La semántica precisa, simple y útil (independiente de una implementación o ejecución en particular) también se pierde a menudo. Echa un vistazo a mi respuesta a "Especificación para un lenguaje de programación Reactivo Funcional", y sigue los enlaces allí.

Ya sea en el tiempo o en el espacio, la discretización prematura frustra la componibilidad y complica semántica. Considere los gráficos vectoriales (y otros modelos espacialmente continuos como Pan's). Al igual que con la finitización prematura de estructuras de datos como se explica en Por Qué Importa la Programación Funcional.

No creo que haya ningún beneficio al usar la abstracción de señales/comportamientos sobre las señales estilo elm. Como señala, es posible crear una API de solo señal encima de la API de señal/comportamiento (no está en absoluto lista para usar, pero consulte https://github.com/JohnLato/impulse/blob/dyn2/src/Reactive/Impulse/Syntax2.hs por ejemplo). Estoy bastante seguro de que también es posible escribir una API de señal/comportamiento sobre una API de estilo elm. Eso haría que las dos API funcionalmente equivalente.

WRT efficiency, with a signals-only API the system should have a mechanism where only signals that have updated values will cause recomputations (e.g. if you don't move the mouse, the FRP network won't re-calculate the pointer coordinates and redraw the screen). Siempre que esto se haga, no creo que haya ninguna pérdida de eficiencia en comparación con un enfoque de señales y flujos. Estoy bastante seguro de que Elm funciona así.

No creo que el problema del comportamiento continuo hace cualquier diferencia aquí (o realmente en absoluto). Lo que la gente quiere decir al decir que los comportamientos son continuos en el tiempo es que están definidos en todo momento( es decir, son funciones sobre un dominio continuo); el comportamiento en sí no es una función continua. Pero en realidad no tenemos una manera de muestrear un comportamiento en cualquier momento; solo se pueden muestrear en momentos que corresponden a eventos, ¡así que no podemos usar toda la potencia de esta definición!

Semánticamente, a partir de estos definiciones:

Event    == for some t ∈ T: [(t,a)]
Behavior == ∀ t ∈ T: t -> b

Dado que los comportamientos solo se pueden muestrear en momentos en los que se definen los eventos, podemos crear un nuevo dominio TX donde TX es el conjunto de todos los momentos t en los que se definen los Eventos. Ahora podemos aflojar la definición de Comportamiento a

Behavior == ∀ t ∈ TX: t -> b

Sin perder ninguna potencia (es decir, esto es equivalente a la definición original dentro de los confines de nuestro sistema frp). Ahora podemos enumerar todas las veces en TX para transformar esto en

Behavior == ∀ t ∈ TX: [(t,b)]

Que es idéntica a la definición original Event excepto el dominio y la cuantificación. Ahora podemos cambiar el dominio de Event a TX (por la definición de TX), y la cuantificación de Behavior (desde forall para algunos) y obtenemos

Event    == for some t ∈ TX: [(t,a)]
Behavior == for some t ∈ TX: [(t,b)]

Y ahora Event y Behavior son semánticamente idénticos, por lo que obviamente podrían representarse usando la misma estructura en un sistema FRP. Nos hacen perder un poco de información en este paso; si no diferenciamos entre Event y Behavior no sabemos que Behavior se define en cada tiempo t, pero en la práctica no creo que esto realmente importe mucho. Lo que elm hace IIRC es requerir tanto Events como Behaviors que tengan valores en todo momento y simplemente usar el valor anterior para un Event si no ha cambiado (es decir, cambiar la cuantificación de Event a forall en lugar de cambiar la cuantificación de Behavior). Esto significa que puede tratar todo como una señal y todo Funciona; solo se implementa para que el dominio de la señal sea exactamente el subconjunto de tiempo que el sistema realmente usa.

Creo que esta idea fue presentada en un documento (que no puedo encontrar ahora, alguien más tiene un enlace?) sobre la implementación de FRP en Java, tal vez desde POPL '14? Trabajando de memoria, así que mi esquema no es tan riguroso como la prueba original.

No hay nada que le impida crear un Behavior más definido por ejemplo pure someFunction, esto solo significa que dentro de un sistema FRP no puede hacer uso de esa definición extra, por lo que nada se pierde por un sistema más restringido aplicación.

En cuanto a las señales teóricas como el tiempo, tenga en cuenta que es imposible implementar una señal de tiempo continuo real utilizando lenguajes de programación típicos. Dado que la implementación será necesariamente discreta, convertir eso en una secuencia de eventos es trivial.

En resumen, no creo que nada se pierda usando solo señales.

Desafortunadamente no tengo referencias en mente, pero recuerdo claramente diferentes autores reactivos afirman que esta elección es solo por eficiencia. Expone tanto para dar al programador una opción en lo que la implementación de la misma idea es más eficiente para su problema.

Podría estar mintiendo ahora, pero creo que Elm implementa todo como flujos de eventos bajo el capucha. Sin embargo, cosas como el tiempo no serían tan agradables como las transmisiones de eventos, ya que hay cantidad infinita de eventos durante cualquier marco de tiempo. No estoy seguro de cómo Elm resuelve esto, pero creo que es un buen ejemplo de algo que tiene más sentido como una señal, tanto conceptualmente y en aplicación.