После прочтения довольно любопытной исследовательской работы “Resource Entity Action: A Generalized Design Pattern for RTS games” я решил реализовать предложенную концепцию (в несколько упрощённом виде) на Haskell. Ниже пойдёт речь об идее подхода Resource-Entity-Action к проектированию RTS-игр (Command & Conquer, Age of Empires, StarCraft, …) и прочих симуляций, а также о том, как использовать библиотеку rea. Подход Resource-Entity-Action Предложенная в статье выше идея довольно проста по своей сути: для описания логики некоторой RTS-игры мы используем трансферы абстрактных ресурсов между сущностями.

В данной заметке мы покажем, как функциональное реактивное программирование (FRP) позволяет нам полностью декларативно описать механику графической программы и чрезвычайно упростить её код. В качестве иллюстрации мы напишем незамысловатую программу-рисовалку, которая использует (обыкновенные) императивные биндинги к GTK и Cairo и пользовательский интерфейс которой создан в UI-редакторе Glade. Для FRP мы будем использовать замечательный пакет reactive-banana. Мостик между GTK и reactive-banana заполнит библиотечка reactive-banana-gi-gtk. Подготовка Зависимости нашей программы: text mtl reactive-banana reactive-banana-gi-gtk gi-gtk gi-gdk gi-gobject gi-cairo cairo Этапы построения программы Мы можем разделить процесс создания программы на следующие этапы:

Процесс создания собственных декларативных виджетов в библиотеке gi-gtk-declarative не так уж и сложен. Его можно разбить на следующие шаги: Измышление механики будущего виджета, понимание нижележащих GTK-виджетов, его составляющих Описание типа меняемых пользователем параметров (properties) виджета - для установления чистой функциональной зависимости от структуры пользователя. Описание типа всех событий (events), которые будет генерировать виджет (например, в ответ на срабатывания сигналов внутренних GTK-виджетов или достижения определённых состояний автомата логики) Описание внутреннего стэйта нашего виджета (например, поддерживание набора составляющих низкоуровневых GTK-виджетов для доступа к их состояниям) Создание пяти функций, необходимых для конструирования значения типа CustomWidget widget customData event (что в свою очередь даст нам искомый Widget event): data CustomWidget widget customData event = CustomWidget { customWidget :: Gtk.

Императивный GTK Программирование графических (GUI) приложений популярным императивным способом возможно и на Haskell: при таком подходе мы обычно работаем в монаде IO (или в параметризованном IO трансформере, например StateT) и логика программы частенько полностью идентична императивным языкам. Например, программа ниже использует библиотеку GTK3 в императивном стиле (низкоуровневые биндинги к GTK3 пакетом gi-gtk): import qualified GI.Gtk as Gtk import Data.GI.Base main :: IO () main = do Gtk.init Nothing win <- new Gtk.

Фундаментальные трансформеры монад ReaderT (read-only контекст: например, настройки программы из конфигурационного файла), WriterT (write-only контекст: например, лог работы программы) и StateT (read/write контекст: например, счётчики и прочее внутреннее состояние логики программы) стандартных библиотек mtl и transformers очень употребительны. Их можно композиционно параметризовать любой “объемлющей” монадой для моделирования требуемого вычислительного контекста (например, WriterT w IO для программы, которая общается по сети и протоколирует (логирует) свою работу моноидом r). Трансформеры легко параметризуются друг-другом; мы работает с вложенными в “стопку” монадами путём лифтинга комбинаторов к нужным монадам с помощью функций семейства lift.