Функциональные языки и GUI.

haskell что-то имеет

Си, гикг расскажек как он крут функцианально и гуево.

Да их всего 2, распространенных - Ocaml и Haskell, в обоих есть GUI-библиотеки.

Ну если считать Scala и F# - то там всё понятно.

У Common Lisp - куча. В основном линуксовские биндинги.

Для Qt есть что-нить?

wxHaskell, wxGtk в PLT Scheme, wxErlang, cl-gtk, ....

С этим плохо, потому как C++
хотя вроде вот что-то: http://sourceforge.net/projects/lisp-cffi-qt4

Вообще, вот список для CL:
http://www.cliki.net/Graphics%20Toolkit
Под винду можно использовать RDNZL:
http://weitz.de/rdnzl/

haskell+gtk2hs

Коня и трепетную лань... den73

У хаскелля есть более чем практичный gtk2hs, и элегантные Fudgets (+ несколько их современных клонов в виде надстроек над gtk2hs/wx). У лиспа есть такой шедевр, как CLIM.

Не сочтите за троллинг. Вчера вечером открыл clojure и увидел, что язык сильно "зафункционаленный". Первое, чем они гордятся - это немодифицируемые структуры. Типа, круто, копировать массив ради того, чтобы изменить один элемент.

Я не понимаю, как это может согласоваться с гуем вообще. Ведь "создать окно" - это чистый императив. ФП могло бы пригодиться на этапе фантазий и планов. Т.е., для реализации в программе мыслей типа: "А вот если мы бы подали команду открыть окно, то на экране показался бы квадратик". Тогда экран и список зарегистрированных в системе окон могут быть состоянием, которое можно передавать по значению. Раз оно существует только в нашей фантазии, мы можем создать сколько угодно копий этого окна. Но нам будет тяжело спуститься с абстрактного уровня на прикладной. Тяжело будет также реализовать конкретное приложение эффективно и выразить его лаконично.

В реальной же жизни, ГУЙ выглядит несколько проще: у нас существует, обычно один пользователь (а не счётное множество), один экран, на котором нарисовано что-то конкретное. Если экран - это экран веб-браузера на другом компе, а мы пишем серверную часть, основанную на продолжениях, то всё равно,основные трудности у нас имеют практический характер, а сама инкапсуляция состояния - это, в общем-то, проходная тема.

Да, в некоторых случаях может понадобиться иметь несколько образов экрана (например, несколько рабочих пространств или удалённый рабочий стол). Может понадобиться сохранить состояние приложения (хотя это тоже задача довольно ехидная, и чистое ФП тут мало поможет, т.к. приложение всё равно существует в контексте внешних связей, которые меняются когда хотят без нашего ведома). Я уверен, что современные ФП языки реально не способны эффективно представить состояние операционной системы типа линукса и эффективно же передавать его по значению. Если бы операционная система была с нуля построена на ФП, то тогда это было бы ещё обсуждаемо. А так это вряд ли реально. Если мы пытаемся выразить императивные действия через ФП (один пользователь за одним экраном, который работает прямо сейчас и которому не нужно возвращаться в прошлое), то нам нужен очень хороший компилятор, который правильно разгадает эту ситуацию и превратит наши ФП фантазии в эффективный императивный код. Если мы скопировали состояние и известно, что исходное значение нам никогда больше не понадобится, то компилятор должен сгенерировать код, меняющий существующее состояние.

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

Если мы сравним это с современным состоянием ФП языков, то мы видим, что тут ещё "конь не валялся". В Хаскеле, на тот момент, когда я обратил к нему свой интерес, это не было реализовано даже для такого примитива, как хеш-таблица.

На самом деле, можно, нужно и не так тяжело сделать функционально-чистую хеш-таблицу. Без хеш-таблиц писать содержательные приложения практически невозможно. С хеш-таблицами на хаскеле невозможно писать чистые ФП приложения. Мораль: на Хаскеле невозможно писать приложения реального мира, не отступая от духа языка. Вывод: для работы с ГУИ Хаскель не оптимален. Если уж пофлеймить, то авторы Хаскеля - это люди, оторванные от реальности, они не программисты, и вообще люди не слишком умные. Замысел должен быть целостным и раскрытым. В хаскеле замысел чистого ФП не раскрыт. Если бы я писал чистый ФП язык, я бы скорее не стал бы париться с выведением типов (типы вообще не имеют отношения к идее ФП), но хотя бы какую-нибудь реализацию чистых хеш-таблиц я бы сделал обязательно. Также при определённых условиях можно сделать чистыми и потоки. Должна быть возможность делать программу ФП чистой, если эти условия соблюдаются. Например, мастер инсталляции содержит в себе большой кусок, который по смыслу хорошо моделируется чистым ФП, хотя он может читать файлы. Теряется чистое ФП только в тот момент, когда он начинает реально устанавливать. Однако, сам сценарий установки является работой чистой ФП программы. Процесс чтения конфигурации в процессе генерации этого сценария - это тоже процесс, который можно условно считать чистым (если конфигурация не меняется между чтением и записью).

Итак, окончательная мораль: удовлетворительных ФП языков, акцентирующихся на чистоте, на сегодня не существует. Понимания этой проблемы у адептов ФП нет, а значит, нет и стимула к изменениям. Технология не пригодна к применению и пока проблемы не будут осознаны и решены, она так и останется чем-то академическим.

Всё сказанное не относится к лиспу, т.к., лисп - это императивный язык (вопреки тому, что про него думают неосведомленные люди). Также я не особо строг к ocaml, т.к. он, насколько я знаю, не вводит наказания за нечистоту ФП. Именно Хаскель вводит такое наказание на уровне языка, при этом, не предоставляя достаточных, возможных и легко реализуемых чистых ФП средств. Получается, что Хаскель наказывает пользователя за то, что сам Хаскель недоделан. Я не мазохист, спасибо. Однако, увы, этот вопрос больше не получается просто игнорировать, поэтому я про это и пишу. Проблемой является clojure.

Я не видел никаких биндингов ФП языков к ГУИ (хотя я видел widget library для AJAX и в своё время я сделал proof of concept для биндингов Borland VCL к Common Lisp). У меня есть чёткое ощущение, что при борьбе за чистоту ФП биндинги будут либо убоги по функционалу (включать в себя только то, что легко моделируется в рамках ФП), либо противоестественны в рамках самой ФП идеологи.

Хотелось бы услышать комментарии от тех людей, которые не находятся под харизмой ФП и которые пробовали такие биндинги. Для меня этот вопрос имеет практическую значимость. Я разочарован в Common Lisp, этот язык болен и не лечится. Я возлагал надежды на clojure, но теперь я вижу, что он страдает функциональной чистотой. Я хотел бы обострить этот вопрос, проработать его и понять, действительно ли ФП языки непригодны для ГУИ или я просто чего-то недопонимаю.

Также интересны люди, которые написали что-нибудь содержательное на clojure (это не офтопик здесь).

den73

Ага, только gtk2hs вусмерть отказывается нативно работать под Mac OS X. WxHaskell - полёт нормальный.

Вранье. Окошко - это по сути машина состояний, которая обрабатывает входящие сообщения. Текущее состояние определяет способ обработки сообщения. В то же время сообщение модифицирует состояние. В императивном коде это приводит к гнилому болоту из if-ов, switch-ей и прочего _овна.

Да, с созданием машины состояний на плюсах чувствую, поседею скоро. Свой препроцессор пейсать a-la Qt -- нахрен ещё один велосипед? Потому и присматриваюсь к функциональщине и привязках к существующим библиотекам. А насчёт графики тикля кто что скажет хорошего?

Хорошая графика. На мой непрезентабельный вкус.

Я, эта, некорректно выразился немного. Хотел узнать, как у тикля с привязками к функциональщине, например, к GCL.

gcl - этож лисп, несовсем функциональный, работал с ltk в sbcl и clisp правда давно, впечатления положительные, работало в линуксе и в винде

> этож лисп, несовсем функциональный

Ну, я-ж не религиозный фанатик функциональной чистоты языка. :-)

А как та привязка тикля к LISP обзывалась?

> А насчёт графики тикля кто что скажет хорошего?

Я скажу. Tk --- хорошая графика :)

> А как та привязка тикля к LISP обзывалась?

М.б. имелось в виду ltk? http://www.peter-herth.de/ltk/

>Да, с созданием машины состояний на плюсах чувствую, поседею скоро

Посмотри здесь
http://labs.trolltech.com/blogs/2009/01/30/qt-state-machine-framework/

Почитай про FRP чтоли, тот же Fudgets, Pan, ... http://www.haskell.org/yale/papers/haskellworkshop02/workshop-02.ps.gz

2den73

Да, эти проблемы есть. Но они не имеют принципиальный характер. Идут активные исследования, находятся интересные элегантные решения. Косяки лезут в основном из императивного мира, т.к. функциональной программе приходится в нём жить. Решение, которое я прорабатываю - большая база данных для хранения всего состояния и чистые обвязки (как в FRP, без loop). Изнутри это будет напоминать что-то типа Simulink'а/LabVIEW.

Система типов хаскелля тоже весьма ограничена. Но опять же, это не значит, что на типы надо клать болт. Есть очень интересные системы, типа OTT (язык Epigram), много чего опять же в активной разработке.

PS Да, императивным программам в функциональной среде тоже тяжко :) http://augustss.blogspot.com/2009/02/regression-they-say-that-as-you-get.html

Не пойму как CL относится к сабжу. Вам трудно угодить. Все пишут на CL и GUI в том числе, а у вас почему-то не получается, ясное дело язык плохой. А мож с руками что-то ?