Ich versuche einen springenden Ball mit dem Yampa-Framework zu simulieren: Bei gegebener x-Position, Höhe und Geschwindigkeit sollte der Ball nach den Schwerkraftregeln springen. Die Signalfunktion nimmt ein "Tip-Event" als Eingabe, die Idee ist "wenn der Ball gekippt wird, sollte sich die Geschwindigkeit verdoppeln".
Der Ball springt gut, aber jedes Mal, wenn ein Kippereignis eintritt, geht die Funktion in eine Endlosschleife über. Ich dachte, dass ich wahrscheinlich eine Verzögerung hinzufügen muss (dSwitch, pre, notYet?), Aber ich weiß nicht wie. Jede Hilfe wäre willkommen!
%Vor%BEARBEITEN: Ich habe es geschafft, die Endlosschleife zu vermeiden, indem ich eine Flagge zurückgab, wenn ein Tipp auftrat, aber das fühlt sich immer noch nicht wie der richtige Weg an ...
%Vor% Nach ein paar Tagen Hacking denke ich, dass ich die Antwort gefunden habe. Der Trick besteht darin, notYet zu verwenden, um das Switching-Ereignis auf den nächsten Zeitpunkt zu verschieben, so dass das Umschalten (und somit der rekursive Aufruf von fly ) stattfindet, wenn das "alte" Tippereignis vorüber ist. Die Funktion second stellt sicher, dass nur der zweite Teil des Ergebnistupels (Ball, Event (..)) durch notYet gesetzt wird. Dadurch wird die Endlosschleife entfernt, aber auch die Semantik geändert: Die Umschaltung erfolgt nun erst um einen "Zeitschritt" später, dies wiederum führt zu einer anderen Geschwindigkeit.
Diese Yampa-Sache ist eigentlich ganz nett, leider gibt es nicht viel Dokumentation zu finden. Ich konnte immer noch nicht herausfinden, wofür die Funktionen pre und iPre gut sind, ich denke, sie können in einem ähnlichen Kontext verwendet werden.
Tags und Links haskell reactive-programming frp