И еще

[metaclass]

Писать GUI на хаскеле - это все равно, что писать GUI на SQL.

Если обернуть фразу - то для того, чтобы сделать нормальный GUI фреймворк для хаскеля (а не сплошную имитацию императивщины на монадах), нужно представить GUI в декларативно-функционально-теоретико-множественном стиле :)

Comments

[jtootf.livejournal.com]

Phooey (http://darcs.haskell.org/packages/phooey/doc/html/Graphics-UI-Phooey-Applicative.html), Fudgets (http://www.cs.chalmers.se/ComputingScience/Research/Functional/Fudgets/springschool95-intro.html)

вполне себе функционально. кстати, а где в описании GUI нужна императивщина?

[metaclass.livejournal.com]

Видел я скриншоты GUI на этом. За такое с работы увольняют.
Но вообще идея насчет комбинирования GUI из элементов сама по себе правильная.

А императивщина нужна, когда GUI сильно динамический, т.е. юзер ткнул в один элемент - десять других поменяли свое состояние. Я делал декларативное описание такого на XML - этот продукт в процессе разработки потерял поддерживаемость года где-то за два, сейчас буду переделывать и переносить декларативные описания внутрь кода(структура примерно такая же, но в качестве описания будет структура .NET класса, управляющего GUI, а всякие проверки и прочее - чисто императивный код).

[jtootf.livejournal.com]

это не императивщина, это уже event-driven. а как раз в event-driven функциональщина чувствует себя очень неплохо - можно смотреть FRP, работы Элиотта, YAMPA (AFRP)

ну а что GUI страшное, так речь не о том; это - интерфейс, снизу к нему хоть Qt пристегнуть можно, хоть GTK# (насчёт WinForms не уверен)

[metaclass.livejournal.com]

Да, FRP, видимо, должно подойти. Промоделировать юзера как две сущности - одна генератор событий, а вторая - функция, преобразующая вывод программы в вводимые данные :)