haskell - reactive programming languages
¿Nos importa el "pasado" en FRP? (1)
Al jugar con la implementación de FRP, una cosa que he encontrado que es confusa es, ¿qué hacer con el pasado? Básicamente, entendí que sería capaz de hacer esto con un Comportamiento en cualquier momento:
beh.at(x) // where time x < now
Esto parece que podría ser problemático en cuanto a rendimiento en un caso como este:
val beh = Stepper(0, event) // stepwise behaviour
Aquí podemos ver que para evaluar el Comportamiento en el pasado necesitamos mantener todos los Eventos y terminaremos realizando (en el peor de los casos) escaneos lineales cada vez que muestreamos.
¿Queremos que esta capacidad esté disponible o debemos permitir que solo se evalúen los comportamientos a la vez> = ahora? ¿Incluso queremos exponer la función at al programador?
Si bien se considera que un comportamiento es una función del tiempo, la dependencia de una cantidad arbitraria de datos pasados en FRP es una Cosa Mala, y se conoce como una fuga de tiempo . Es decir, las transformaciones en los comportamientos generalmente deben ser continuas / reactivas, ya que no se basan en más que una cantidad limitada del pasado (y deben acumular este conocimiento de la historia de manera explícita ).
Entonces, no, at no es deseable en un sistema real de FRP: no debería ser posible mirar el pasado o el futuro. (Esto último es, por supuesto, imposible, si el estado del futuro depende de algo externo al sistema de FRP).
Por supuesto, esto lleva al problema de que solo poder mirar el presente exacto restringe severamente lo que puede hacer cuando escribe una función para transformar comportamientos: Behaviour a -> Behaviour b convierte en el mismo que a -> b , lo que hace que muchos Cosas que nos gustaría hacer imposibles. Pero esto es más una cuestión de encontrar una semántica, uno de los problemas persistentes de FRP, que cualquier otra cosa; Siempre que las transformaciones primitivas en los comportamientos que proporcione sean lo suficientemente potentes sin causar pérdidas de tiempo, todo debería estar bien. Para obtener más información sobre esto, vea Basura que recopila la semántica de FRP .