Функциональный апартеид

[metaclass]

http://udpn.livejournal.com/78084.html?style=mine
Обычно говорят, что нормальный порядок редукции нужен для того, чтобы bottom в аргументе не превращался в bottom в результате всегда, когда это возможно. Само по себе это никому не нужно. Дело именно в отложенном вычислении аргументов. Чтобы определить управляющие конструкции в языке с аппл. порядком редукции, нужно это делать явно, и их можно ввести только конечное число на этапе разработки языка. С нормальным порядком мы имеем возможность определять новые конструкции в любом количестве.

Всех, кто ничего не понял - отправить в индию и бангладеш, купаться в ганге и поклонятся коровам.

Comments

[falcrum.livejournal.com]

Хм-м, все, кто не пользуют функциональное программирование - индусы? Однако... :)

[nicka-startcev.livejournal.com]

это фашизм!
Я, честный труженик села с полным ртом полными руками навоза, протестую!

[metaclass.livejournal.com]

Использовать не обязательно, но представлять разницу полезно.
http://xoposhiy.livejournal.com/88565.html

Ключевой момент - возможность расширять/реализовывать некоторые конструкции, не меняя компилятор языка - без этого начинается всякий закат солнца вручную.

Впрочем, иногда бывает так, что вроде как бы и можно все делать, но выглядит это при реализации так, что лучше бы этого не было :)

[molnij.livejournal.com]

Вы бы хоть уточняли что людей определенной профессии, а то многие могут посмотреть с недоумением

[si14.livejournal.com]

Спорно. Не во всех функциональных языках нормальный порядок редукции (скорее даже в большинстве аппликативный). Scala, Clojure, Erlang, Ocaml — не функциональные языки?

[justy-tylor.livejournal.com]

Ой, какая древняя зефировщина... :) Управляющие конструкции при ленивости вводятся лишь до определённого предела. Очередной комбинатор !@!@#$% - легко. Что-то уровня do notation - никак. Но, как гласят легенды, истинному программисту на Хаскеле и не должно хотеться лучшего.

[nivanych.livejournal.com]

С ленивостью одна большая проблема — это полный пофигизм по отношению к ресурсной семантике.
И даже в современных языках, все эти проблемы решаются ad hoc.
Вроде как, имеешь опыт работы с ленивостью — должен сообразить.
А не сообразил, и ВНЕЗАПНО, где-то-там у тебя прорвало — сам виноват.
Рассуждения о ресурсной семантике (не без помощи линейной логики!) нормализации в ламбда-исчислении приводят к оптимальной редукции, о которой немало писал codedot. Хоть он всё делает для бестиповой лямбды, но и такое изучить небесполезно.

[aamonster.livejournal.com]

А что, это не одно и то же?

[metaclass.livejournal.com]

Хм, оптимальный порядок редукции это интересно. Это ж будет "странная" комбинация аппликативного и нормального, которую мы сейчас обычно закатываем солнцем вручную.

[gds.livejournal.com]

+1. А вот в Coq, где синтаксис расширяется отнюдь не через подобные функции, а через более правильный механизм Notations, вполне делается do-нотация.
И в окамле подобное решается без лентяйки -- достаточно написать camlp4-расширение (или, с новым подходом, который уже в транке, но ещё не в релизе, всего лишь функцию на 20 строк, что ещё проще).

[nivanych.livejournal.com]

Что именно одно и тоже?...

[nivanych.livejournal.com]

Дворники, например.
Я думаю, ребе М тут со мной согласен.

[nivanych.livejournal.com]

Нуу, можно считать это комбинацией аппликативного и нормального, скорее всего (полностью не уверен).
Но сколько я видел, это рассматривают с другой стороны.

[jakobz.livejournal.com]

Обычно говорят что нормальный порядок нужен для <общее определение>, но на деле оно для <частный случай>

[jakobz.livejournal.com]

Это, кстати, в SICP разбирается в первой главе, в примере где типа "Маша-дурняша хочет захуярить if, почему она соснет".

[aamonster.livejournal.com]

"чтобы bottom в аргументе не превращался в bottom в результате всегда, когда это возможно", "отложенное вычисление аргументов" и возможность "определить управляющие конструкции"?

Ну, если вдаваться в тонкости - то разное (например, в Форте нет ленивости - но новые управляющие конструкции определяются свободно), но в контексте ФП...

[udpn.livejournal.com]

Вот, суть уже пробивается.

[si14.livejournal.com]

Это вы к тому, что не являются? Достаточно спорно.

Впрочем, в кложуре аппликативный порядок не мешает вводить какие угодно операторы — да здравствуют макросы.

[udpn.livejournal.com]

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

[udpn.livejournal.com]

Кстати да, всегда интересно было, о чём пишет codedot, но пишет он очень сложно.

Под "оптимальностью" подразумевается минимальное количество вычислений согласно некоторому определению этого "количества"? Просто я не вижу причин уходить дальше редукции на графах, а они, судя по всему, есть (затраты памяти или на косвенность, не знаю).

[udpn.livejournal.com]

Неправда. Вот я могу зависимыми типами и проверкой тотальности вообще убрать bottom из языка. В чём тогда будет разница между нормальным и аппликативным порядками? А она будет. В одном случае аргументы if_then_else_ будут вычисляться все, а в другом — только нужные. Если не ошибаюсь, это называется как раз "операционной семантикой."

[udpn.livejournal.com]

Что "это"?

[jakobz.livejournal.com]

Возможность написания своих управляющих конструкций на ленивом языке.

[gds.livejournal.com]

нет, это не просто другая запись функций. (иначе как бы я сделал do-нотацию? там же явно требуется "a <- b" транслировать в "b >>= fun a -> ...")
Ну и вот, чтобы не быть голословным, покажу няшечьку: http://paste.in.ua/4459/ -- судя по коду, который экстрактится в окамл, вычисляется только одно из выражений.

[jakobz.livejournal.com]

Да, пожалуй ты прав, именно bottom тут не причем. Хотя убрать его совсем не выйдет, проблема остановки же есть.

Но управляющие конструкции - тоже только один из углов более хитрой проблемы.