Andrei F.,

AVK>>UI то, конечно, делать можно. Проблема в дизайн-тайме, причем не только этого самого UI. Сколько я ни спрашивал, никто не смог мне продемонстрировать чисто функциональную компонентную модель. Что, впрочем, не мешает при этом какими то элементами ФП пользоваться.

AF>Любой интерфейс должен иметь состояние — просто потому, что пользователь так устроен Так что делать его в идеологии ФП — все равно что бегать в ластах.

Нет.

Состояние может существовать просто согласно постановке задачи (например, stateful протокол). Для того, чтобы состояние не рассыпалось, конечно достаточно линеаризации мутаторов и аксессоров, и так делают все императивные языки. Однако, это не необходимое условие. Для корректного сохранения состояния достаточно соблюдать относительный порядок вызовов мутаторов и аксессоров.

Один из подходов — это монады, о них ты уже много раз слышал. Формируется ФВП, связывающая аргумент и цепочку мутаторов/аксессоров, таким образом сохраняющая относительный порядок и таким образом поддерживающая состояние в корректном гхм... состоянии Итоговая конструкция скорее не "последовательная", а "вложенная", и обладает несимметричностью (слева значение, а справа функцию (условно говоря, ибо функции тоже значения)).

Другой подход. Теперь мы говорим, что эти обращения к состоянию образуют поток (то есть вводим понятие функционального потока). Мы можем, если хотим, производить различные операции над такими потоками, эти операции будут порождать другие потоки. Операции над потоками обобщаются до стрелок (в случае хаскеля просто класс типов Arrow). В деталях эта абстракция довольно сложна, но пользоваться ею (при наличии необходимых примитивов) вполне нормально:

    appWindow :: CompCircuit Window () (() :& QuitReq)
    appWindow = proc () -> do
        () :& Destruction := destruction
            <- unit (ordinaryWindow windowContent) -< () :& Title := constant "Accumulation demo"
        returnA -< () :& QuitReq := destruction