Каркас пользовательского интерфейса Haskell? - PullRequest
19 голосов
/ 19 мая 2010

Есть, случайно, новая среда пользовательского интерфейса Haskell для Windows?

Я недавно начал изучать язык, и, насколько я вижу, это было бы для отличных маленьких одноразовых приложений (сложных скриптов).

Тем не менее, без хорошей структуры пользовательского интерфейса я не вижу, как она проникает под дым и зеркала более очевидных соперников.

Я читал, что есть много фреймворков, но ни один из них не является полнофункциональным.

Мне просто интересно, если это то, что находится на подъеме, или просто слишком сложно заставить достаточно разработчиков идти в одном направлении с одним?

Ответы [ 3 ]

18 голосов
/ 19 мая 2010

Два основных каркаса: wxHaskell и Gtk2Hs . Оба из них были использованы для реальной работы. Из того, что я знаю, я бы предпочел Gtk2Hs, потому что он правильно обрабатывает ресурсы (то есть использует GC). wxHaskell требует, чтобы программист выпустил виджеты, когда они больше не нужны, поэтому вы можете получить все классические утечки памяти и устаревшие винты указателя.

Проблема обоих заключается в том, что все находится в монаде IO. Это отражает тот факт, что они являются сравнительно тонкими оболочками вокруг существующих библиотек графического интерфейса для обязательных языков. Конечно, это означает, что вы не хуже, чем если бы вы писали графический интерфейс на императивном языке, но вряд ли вам это намного лучше.

Есть несколько интересных экспериментальных библиотек, которые можно найти на Hackage, в том числе идеи Грейпфрута и Конала Эллиота "Tangible Values" в GuiTV. Оба они пытаются использовать более декларативный подход.

7 голосов
/ 24 мая 2010

(Отказ от ответственности: я сопровождающий wxHaskell)

И wxHaskell, и Gtk2H более или менее полны. Иными словами, оба оборачивают большую часть функциональности, предоставляемой их базовыми библиотеками. Оба они, как упоминалось ранее, требуют довольно «императивного» стиля программирования в монаде IO.

Было много дискуссий об относительных достоинствах каждого из них. Я бы сказал, что wxHaskell легче всего работать, особенно в Windows, так как его можно установить через cabal (см. http://www.haskell.org/haskellwiki/WxHaskell/Install#On_Windows)

Фреймворки FRP (Grapefruit и другие) обеспечивают более «функциональный» стиль программирования за счет значительного сокращения охвата виджетов. У меня такое ощущение, что это все еще открытая область исследований, и она не готова к «прайм-тайму».

На практике у меня никогда не было проблем с управлением ресурсами с wxHaskell, хотя я согласен, что это возможно, и эта область лучше обрабатывается Gtk2Hs, которая использует подсчет ссылок в базовой библиотеке.

В целях полноты я должен также упомянуть, что существует также привязка Qt (QtHaskell?) - она ​​относительно молода, но, по-видимому, достаточно завершена.

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

1 голос
/ 27 августа 2012

Также вы можете использовать wxWidgets (я имею в виду библиотеку C ++) с Haskell. Вот пример: https://bitbucket.org/afiskon/hs-a-star-gui/src Такой подход имеет некоторые преимущества перед wxHaskell: 1. Вы можете использовать генераторы пользовательского интерфейса (Code :: Blocks, wxFormBuilder) 2. Ваше приложение занимает меньше места на диске 3. Вы можете использовать все функции wxWidgets.

Следует также отметить, что в последней версии wxHaskell используется wxWidgets 2.9, который, вероятно, никогда не будет перенесен в Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=16;bug=613431

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...