haskell - ¿Ayuda el push-pull FRP a la hora de implementar juegos?

reactive-banana netwire (1)

Por lo que puedo leer here y there , Netwire y reactive-banana tienen diferentes propósitos y objetivos. Netwire se especializa en el modelado de señales enmarcadas, como un servidor de juegos, porque lo que un servidor de juegos suele hacer es enviar su estado al cliente en marcos periódicos. Reactive-banana sería la mejor opción para crear una GUI porque una GUI es un modelo puramente basado en eventos y no es tolerante a la fuga de tiempo.

Me parece que puedes usar ambos, dependiendo del aspecto que quieras implementar.

He estado comparando el FRP de solo extracción (es decir, la red) con el de FRP de empuje y extracción (es decir, reactivo-bannana) en la implementación de juegos. ¿Hay ventajas para uno sobre el otro? Las cosas que he notado son:

Los eventos push facilitan la realización de eventos para clics con el mouse / pulsaciones de teclas de GLFW o GLUT
El FRP con flecha que utiliza netwire tiene mucho menos IO flotando, lo que siempre es mejor.
Parece que tener respuestas de solo extracción a cosas como el movimiento del mouse podría causar pérdidas de tiempo.

¿Qué más me he perdido?

Edite, para que esto no se base en la opinión: el objetivo principal es tener algo que sea lo más expresivo / conciso posible, sin pérdidas de tiempo.

Actualización: un gran problema que he encontrado con Netwire es que no parece haber una manera conveniente de tener más de una tasa de cuadros, como se describe en el artículo "Arregla tu paso del tiempo".

Actualización 2: La forma en que he logrado esto es hacer que mi cable de simulación de juego devuelva un Float -> IO () que toma el valor alfa y hace todas las llamadas GL con todo lo interpolado por ese alfa. Idealmente, debería poder pasar esta "función de dibujo" a otro hilo a través de un MVar y ejecutarlo en ese hilo. Hombre, Haskell es impresionante.

Actualización 3: En los seis meses desde que hice esta pregunta, desarrollé un motor de representación simple basado en Netwire y el concepto de "programación de componentes de entidad". En este proceso, en realidad no he encontrado que el uso de FRP sea terriblemente útil. La expresividad de Wire s ha resultado ser un obstáculo en algunas circunstancias. El problema se centra en torno a la "identidad" de los objetos. Al definir un valor de tipo de Wire , no tiene identidad, es decir, puede reutilizarse en la red general varias veces y representar diferentes cosas físicas cada vez. Este es un gran dolor cuando se quiere hacer algo como la detección de colisiones, y no hay manera de atravesar el gráfico de la escena, porque no puede existir sin estar fusionado en un solo cable opaco. Este problema no ocurre en los ejemplos de "juguete", porque es fácil especificar exactamente qué propiedades de qué objetos interactúan con qué otros objetos de qué manera. Creo que este es un problema con cualquier tipo de FRP.

Sería increíble si algún mago de Haskell demostrara que estoy equivocado en esto, pero realmente no veo una forma de evitarlo. También lamento que la explicación no sea buena, pero en realidad no es tan fácil de entender sin intentarlo usted mismo.