Я сравнивал только pull-only FRP (т.е. netwire) с push-pull FRP (т.е. реактивный банан) при реализации игр. Есть ли преимущества у одного перед другим? Вещи, которые я заметил:
- Push-события упрощают создание событий для щелчков мышью/нажатий клавиш из GLFW или GLUT.
- Arrowized FRP, который использует netwire, имеет гораздо меньше
IOплавающего вокруг, что всегда лучше. - Похоже, что ответы только по запросу на такие вещи, как движение мыши, могут вызвать утечку времени.
Что еще я пропустил?
Отредактируйте, чтобы сделать это менее основанным на мнении: главная цель — сделать что-то максимально выразительное/краткое, без утечек времени.
Обновление: большая проблема, которую я обнаружил с Netwire, заключается в том, что, похоже, нет удобного способа иметь более одной частоты кадров, как описано в статье «Исправьте свой временной шаг».
Обновление 2: способ, которым я обошел это, состоит в том, чтобы заставить мою проводную симуляцию игры возвращать Float -> IO (), которая принимает альфа-значение и выполняет все вызовы GL со всем, что интерполируется этой альфой. В идеале я должен иметь возможность передать эту «функцию рисования» в другой поток через MVar и запустить ее в этом потоке. Чувак, Haskell — это круто.
Обновление 3. За шесть месяцев, прошедших после того, как я задал этот вопрос, я разработал простой движок рендеринга. a> основанный на Netwire и концепции «программирования сущностных компонентов». В этом процессе я на самом деле не нашел использование FRP очень полезным. Выразительность Wires фактически оказалась помехой в некоторых обстоятельствах. Проблема сосредоточена вокруг «идентичности» объектов. При определении значения типа Wire оно не имеет идентичности, т. е. может повторно использоваться во всей сети несколько раз и каждый раз представлять разные физические объекты. Это огромная боль, когда вы хотите сделать что-то вроде обнаружения столкновений и не можете пройти по графу сцены, потому что он не может существовать без слияния в один непрозрачный провод. Эта проблема не возникает в "игрушечных" примерах, потому что легко точно указать, какие свойства каких объектов и каким образом взаимодействуют с другими объектами. Я считаю, что это проблема с любым типом FRP.
Было бы здорово, если бы какой-нибудь волшебник Haskell доказал, что я ошибаюсь, но я не вижу способа обойти это. Также мне жаль, если объяснение не очень хорошее, но на самом деле это не так просто понять, не попробовав самостоятельно.
