Комментарии 18
Зачем ломать голову над тем, что непонятно? Ну не лежит душа, и фиг с ним, с Хаскелем.
Мне кажется, шаги здесь немного перепутаны: каррирование надо делать раньше перехода к продолжениям, иначе продолжения выглядят бессмысленно.
Так вот оно как оказывается называется.
Сначала из языка выкидывается состояние как вредное, опасное и чреватое ошибками. Потом оно тайком вносится в язык, только обернутое плотным туманом ничего не делающих функций, вызывающих функции и передающих им функции, а под этим флером скрывается банальное копирование всех меняющихся объектов с тайным убиением старых, чтобы никто не заметил, что смена состояния из отдельных объектов переносится в смену состояния всей исполняющей системы.
Таким образом, мы приходим все к тому же банальному
Автору и переводчику спасибо за то, что тайное сделали явным.
Таким образом, мы приходим все к тому же банальному
а:=2, но выполненному per anum, требующему x10 ресурсов для своей работы, непонятному для простых смертных и сакральному для непростых.Автору и переводчику спасибо за то, что тайное сделали явным.
Состояние остается, выкидывается только изменяемое состояние.
Там ничего не выкидывается. Просто изначально, в математической модели языка, никаких изменяемых состояний нет. Монады его в язык опять же не вносят. Монады — это просто один из pattern-ов функционального программирования, чтобы вручную не протаскивать аргументы между вызовами функций.
А сразу сделать изменяемые состояния с сохранением строгости математического подхода не получается. Не умеет математика адекватно описывать изменяющиеся сущности (пока или принципиально — это вопрос). Если пытаться начать это делать, всё равно, придём к тому, что надо будет описывать состояние системы какой-нибудь функцией, задающей значения в ячейках памяти, менять эту функцию целиком при записях, протаскивать её между операторами (для этого как раз монады и нужны) и т.д. и т.п.
Так что, корень проблемы в математике и в том, как мы формально рассуждаем, а совсем не произволе авторов Haskell.
А сразу сделать изменяемые состояния с сохранением строгости математического подхода не получается. Не умеет математика адекватно описывать изменяющиеся сущности (пока или принципиально — это вопрос). Если пытаться начать это делать, всё равно, придём к тому, что надо будет описывать состояние системы какой-нибудь функцией, задающей значения в ячейках памяти, менять эту функцию целиком при записях, протаскивать её между операторами (для этого как раз монады и нужны) и т.д. и т.п.
Так что, корень проблемы в математике и в том, как мы формально рассуждаем, а совсем не произволе авторов Haskell.
Вынесенное состояние, которое затем внесли обратно через монады и линзы — это не только лишняя сложность, но и удобная абстракция.
Для таких состояний проще хранить историю, реализовывать операцию отмены, такое состояние проще сохранять в файл…
Для таких состояний проще хранить историю, реализовывать операцию отмены, такое состояние проще сохранять в файл…
Главная причина, почему на Haskell это выглядит лучше, это поддержка монад на уровне синтаксиса в виде do-нотации.
С помощью ловкости рук и небольшого мошенничества с eval можно реализовать что-то подобное на JS и писать код вида:
var getUser = eval(async(function (eMail) {
id <- db1.getID(eMail);
user <- db2.getData(id);
return user;
}));
Это оказалось побочным эффектом идеи, с которой я пришёл на хабр.
P.S. maxatwork, спасибо большое за перевод интересной статьи!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разбираемся с монадами с помощью Javascript