Как реализуется GUI на чистом функциональном языке без состояния (например, на Haskell)?

Question

[m-haritonov]

Скажите, как на чистом функциональном языке без состояния (например, на Haskell) можно реализовать GUI? Ведь для GUI необходимо состояние (например, для поля ввода нужна переменная, в которую будет сохраняться вводимый в поле ввода текст).

Я не беру в расчёт ситуации, когда для Haskell пишутся GUI библиотеки на другом, более низкоуровневом языке (с состоянием). Мне интересно, как можно реализовать работоспособный GUI элемент (то же поле ввода) на чистом Haskell? И возможно ли это? Видел в обсуждениях упоминание о GUI на Haskell, но какая техника стоит за этим так и не понял.

Answer 1

[leventov]

C чего вы взяли, что в Хаскеле «нет состояния»? С состоянием позволяют работать монады ST, State (трансформер StateT), и, конечно, IO. Это может работать местами менее производительно, без каких-то доп. гарантий, но это полноценная рабочая часть языка — факт. И да, ST и IO вполне можно реализовать на самом Хаскеле.

Вместо изменения значения поля в структуре создается новая структура, дублирующая все поля из старой, кроме поля, которое надо изменить.

Comments

[leventov]

Фактически, State и есть реализация ST на самом Хаскеле. Ее даже в базовом пакете нет, она в пакете mtl.

[m-haritonov]

О том, что в Haskell отсутствует понятие состояния я прочитал в статье на wikibooks.org. Плюс, на сайте haskell.org написано, что он является чистым функциональным языком, что подразумевает обязательную детерминированность функций (зависимость возвращаемого функцией результата только от входных параметров) и отсутствие у них побочных эффектов. Т.е., как я понял, суть подобных языков заключается в определении последовательности функций (дерева функций), одной из которых затем на вход подаются данные, а на выходе получается результат. И за счёт того, что ни одна из функций не может обратиться к внешней переменной (или сохранить данные внутри себя в статических переменных) и достигается хвалёная детерминированность и отсутствие побочных эффектов.

[leventov]

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

Как видите, в такой схеме нет побочных эффектов, недетерминированности и «записи» каких-либо переменных.

[m-haritonov]

leventov, спасибо за разъяснение. Но один момент для меня так и остался непонятным. А именно то, как всё это вписывается в целостную модель работы GUI элемента. Если взять в качестве примера GUI элемента примитивное поле ввода, то для его реализации нам понадобятся (беру по минимуму, предположив, что фокус ввода всегда будет на нашем поле):
— функция для отрисовки прямоугольника на экране: drawRectangle(x1, y1, x2, y2);
— функция для отрисовки текста на экране: drawText(text, x, y);
— функция для сохранения текста (введённого в поле ввода) в оперативную память (для последующего чтения): setFieldValue(text);
— функция для чтения значения, введённого ранее в поле ввода: getFieldValue().

Для простоты обойдёмся без взаимодействия с клавиатурой и другими устройствами ввода. Предположим, что наша программа просто должна при запуске задать в поле ввода некое значение (например, задать для поля значение по умолчанию) и затем считать его. Тогда программа будет выглядеть примерно так (я буду использовать псевдоязык, т.к. не достаточно знаком с синтаксисом Haskell):

// Считаем, что функции drawRectangle, drawText и saveToFile определены в 
// низкоуровневой библиотеке языка

function setFieldValue(text)
{
    drawText(text, 5, 5);

    // А тут надо как-то динамически (во время исполнения программы)  
    // сохранить значение text в оперативную память. Монады? Но как?
}

function getFieldValue()
{
    // Откуда брать сохранённый ранее текст?
}

drawRectangle(0, 0, 200, 50);
setFieldValue("aaa");
saveToFile(getFieldValue());

В данном случае можно, конечно, поступить в чисто функциональном стиле и передать функции setFieldValue вторым аргументом ссылку на функцию saveToFile, которую и вызывать внутри setFieldValue (где ей уже будет доступен параметр text).

Но меня интересует как поступить в ситуации, когда вызов saveToFile выполняется не следом за setFieldValue, а, например, по событию (фактически, когда выполняется другая ветка кода, запускаемая независимо от вызовов цепочки функций из основной ветки кода) — как тут обойтись без записи значения в глобальную переменную?!

[leventov]

function setFieldValue(state, text)
{
    drawText(state, text, 5, 5);
    return (update(state, text), void)
}

function getFieldValue(state)
{
    return (state, get(state))
}

state2, _ = drawRectangle(state, 0, 0, 200, 50);
state3, _ = setFieldValue(state2, "aaa");
state4, fieldValue  = getFieldValue(state3);
state5, _  = saveToFile(state4, fieldValue);

Если нужен конкурентный доступ к состоянию, оно помещается в MVar: hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent-MVar.html

Я сам GUI на Хаскеле никогда не писал, но насколько я знаю, в современных GUI библиотеках на Хаскеле интерфейс программиста делают гораздо более функциональным, в стиле реактивного программирования: www.haskell.org/haskellwiki/Functional_Reactive_Programming

Answer 2

[egorinsk]

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

Comments

[m-haritonov]

Не пойму, что это значит? Я имел ввиду, как можно реализовать GUI элемент без ручного манипулирования состоянием (без изменения значения переменной вручную, например, для записи в неё текста, введённого в поле ввода). Какая встроенная в чистый функциональный язык (язык, в котором нет средств для изменения переменных) техника может избавить от необходимости в таком манипулировании? Интересует не просто чтение состояния переменной на функциональном языке (к кому же фактически ведь такая функция для чтения уже не будет чистой, т.к. её результат не будет зависеть только от входных параметров), а весь процесс создания GUI элемента.

Answer 3

[Михаил Потанин]

Смотрите "Functional Reactive Programming". Упрощенно говоря программа получает поток событий и возвращает поток ответных действий.

Answer 4

[youngmysteriouslight]

Для любого языка имеются библиотеки, написанные на более низком уровне. Для одних языков их больше, для других — меньше.
Как делаются библиотеки под Haskell я не знаю, но Вас интересует именно аспект, связанный с сохранением чистоты при работе с GUI. На уровне использования языка, сохранить чистоту можно, оборачивая все «нечистые» вычисления в монады, например, в IO. Удобно использовать представление, которое в математике называется категорией Клейсли, когда «нечистая» функция A -> B превращается в чистую A -> IO B. Примеры привёл egorinsk комментарием выше.

Comments

[m-haritonov]

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

[Danny]

@m-haritonov, на Python тоже не все вещи можно средствами самого языка реализовать, без низкоуровневых библиотек. Так что это нормально))

Answer 5

[afiskon]

Лучше поздно, чем никогда.

Например. Дело в том, что состояние на самом деле есть, даже в Haskell.

Answer 6

[Maverik]

Думаю, неплохой ответ на этот вопрос можно найти тут