L'aiuto FRP push-pull durante l'implementazione dei giochi?

Question

Ho confrontato il FRP pull-only (cioè netwire) con FRP push-pull (cioè reattivo-bannana) nell'implementazione dei giochi. Ci sono vantaggi per uno rispetto all'altro? Cose che ho le comunicazioni sono:

• eventi push rendere più facile avere eventi per i clic del mouse/tasti premuti da GLFW o GLUT
• Arrowized FRP che NetWire usi è molto meno IO in giro, che è sempre meglio .
• Sembra che avere risposte di sola estrazione a cose come il movimento del mouse potrebbe causare perdite di tempo.

Cos'altro ho perso?

Modifica, per rendere questo meno basato su opinioni: L'obiettivo principale è quello di avere qualcosa che sia il più espressivo/conciso possibile, senza perdite di tempo.

Aggiornamento: Un grosso problema che ho riscontrato con Netwire è che non sembra essere un modo conveniente per avere più di un framerate, come descritto nell'articolo "Correggi il tuo Timestep".

Update 2: Il modo in cui ho ottenuto intorno a questo è quello di rendere il mio filo di simulazione di gioco restituisce un Float -> IO() che assume il valore alfa e fa tutto il GL chiama con tutto interpolato da che l'alfa. Idealmente dovrei essere in grado di passare questa "funzione draw" in un'altra discussione tramite uno MVar ed eseguirlo in quel thread. Uomo, Haskell è fantastico.

Update 3: Nei sei mesi da quando questa domanda, ho sviluppato un simple rendering engine basata intorno NetWire, e il concetto di "programmazione entità-componente." In questo processo, in realtà, non ho trovato l'utilizzo di FRP come estremamente utile. L'espressività di Wire s in realtà è risultata essere un ostacolo in alcune circostanze. Il problema è incentrato sull'identità degli oggetti. Quando si definisce un valore di tipo Wire, non ha identità, cioè può essere riutilizzato nella rete generale più volte e rappresentare ogni volta cose fisiche diverse. Questo è un enorme dolore quando si vuole fare qualcosa come il rilevamento delle collisioni e non avere modo di attraversare il grafico della scena, perché non può esistere senza essere fuso in un unico filo opaco. Questo problema non si verifica in esempi "giocattolo", perché è facile per specify exactly quali proprietà di quali oggetti interagiscono con quali altri oggetti in quali modi. Credo che questo sia un problema con entrambi i tipi di FRP.

Sarebbe fantastico se qualche mago di Haskell mi dimostrasse che non ero d'accordo su questo, ma non vedo davvero un modo per aggirarlo. Inoltre, mi dispiace se la spiegazione non è eccezionale, ma non è così facile da capire senza averla provata tu stesso.

Answer 1

Da quello che posso leggere here e there, Netwire e reactive-banana hanno scopi e scopi diversi. Netwire è specializzato nella modellazione di segnali incorniciati, come ad esempio un server di gioco, perché in genere un server di gioco invia il proprio stato al client in frame periodici. Reactive-banana sarebbe la scelta migliore per creare una GUI perché una GUI è un modello puramente basato sugli eventi e non è tollerante alla perdita di tempo.

Mi sembra che sia possibile utilizzare entrambi, a seconda dell'aspetto che si desidera implementare.